Export limit exceeded: 372951 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (94409 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-24090 | 1 Microsoft | 8 Windows 10, Windows 10 1809, Windows 10 1909 and 5 more | 2026-08-19 | 7.8 High |
| Windows Error Reporting Elevation of Privilege Vulnerability | ||||
| CVE-2021-1640 | 1 Microsoft | 19 Windows 10, Windows 10 1507, Windows 10 1607 and 16 more | 2026-08-19 | 7.8 High |
| Windows Print Spooler Elevation of Privilege Vulnerability | ||||
| CVE-2021-24089 | 1 Microsoft | 2 Hevc Video Extensions, High Efficiency Video Coding | 2026-08-19 | 7.8 High |
| HEVC Video Extensions Remote Code Execution Vulnerability | ||||
| CVE-2026-68147 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.) | ||||
| CVE-2021-27083 | 1 Microsoft | 1 Remote Development | 2026-08-19 | 7.8 High |
| Remote Development Extension for Visual Studio Code Remote Code Execution Vulnerability | ||||
| CVE-2021-27082 | 1 Microsoft | 1 Quantum Development Kit | 2026-08-19 | 7.8 High |
| Quantum Development Kit for Visual Studio Code Remote Code Execution Vulnerability | ||||
| CVE-2021-27081 | 1 Microsoft | 2 Eslint, Visual Studio Code Eslint Extension | 2026-08-19 | 7.8 High |
| Visual Studio Code ESLint Extension Remote Code Execution Vulnerability | ||||
| CVE-2021-27077 | 1 Microsoft | 19 Windows 10, Windows 10 1507, Windows 10 1607 and 16 more | 2026-08-19 | 7.8 High |
| Windows Win32k Elevation of Privilege Vulnerability | ||||
| CVE-2021-27070 | 1 Microsoft | 6 Windows 10, Windows 10 1809, Windows 10 20h2 and 3 more | 2026-08-19 | 7.3 High |
| Windows 10 Update Assistant Elevation of Privilege Vulnerability | ||||
| CVE-2021-27060 | 1 Microsoft | 1 Visual Studio Code | 2026-08-19 | 7.8 High |
| Visual Studio Code Remote Code Execution Vulnerability | ||||
| CVE-2021-24108 | 1 Microsoft | 6 365 Apps, Excel, Office and 3 more | 2026-08-19 | 7.8 High |
| Microsoft Office Remote Code Execution Vulnerability | ||||
| CVE-2026-68143 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch. | ||||
| CVE-2021-24095 | 1 Microsoft | 9 Windows 10, Windows 10 1809, Windows 10 1909 and 6 more | 2026-08-19 | 7 High |
| DirectX Elevation of Privilege Vulnerability | ||||
| CVE-2021-1729 | 1 Microsoft | 9 Windows 10, Windows 10 1809, Windows 10 1909 and 6 more | 2026-08-19 | 7.1 High |
| Windows Update Stack Setup Elevation of Privilege Vulnerability | ||||
| CVE-2026-68142 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the "require CAP_NET_ADMIN in the device netns for changelink" series. Found by 0sec automated security-research tooling (https://0sec.ai). | ||||
| CVE-2026-68141 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated. | ||||
| CVE-2026-68140 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued. | ||||
| CVE-2026-68131 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case. | ||||
| CVE-2026-68129 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet. | ||||
| CVE-2026-68125 | 1 Linux | 1 Linux Kernel | 2026-08-19 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as assoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed. | ||||