Vulnerabilities (CVE)

Filtered by CWE-416
Total 7308 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2026-45593 1 Microsoft 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more 2026-06-11 N/A 7.8 HIGH
Use after free in Windows SDK allows an authorized attacker to elevate privileges locally.
CVE-2026-45596 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-06-11 N/A 7.0 HIGH
Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.
CVE-2026-45599 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-06-11 N/A 8.1 HIGH
Use after free in Universal Plug and Play (upnp.dll) allows an unauthorized attacker to execute code over a network.
CVE-2026-46180 1 Linux 1 Linux Kernel 2026-06-11 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().
CVE-2026-24187 1 Nvidia 1 Gpu Display Driver 2026-06-11 N/A 8.8 HIGH
NVIDIA Display Driver for Linux contains a vulnerability where an attacker could cause a use-after-free. A successful exploit of this vulnerability might lead to denial of service, escalation of privileges, information disclosure, data tampering, and code execution.
CVE-2026-46242 1 Linux 1 Linux Kernel 2026-06-10 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.
CVE-2026-46166 1 Linux 1 Linux Kernel 2026-06-10 N/A 8.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use safe list iteration in radar detect work The call to ieee80211_dfs_cac_cancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error.
CVE-2026-46240 1 Linux 1 Linux Kernel 2026-06-10 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: media: iris: Fix use-after-free in iris_release_internal_buffers() The recent change in commit 1dabf00ee206 ("media: iris: gen1: Destroy internal buffers after FW releases") introduced a regression where session_release_buf() may free the buffer. The caller, iris_release_internal_buffers(), continued to access `buffer` after the call, leading to a potential use-after-free. Fix this by setting BUF_ATTR_PENDING_RELEASE before calling session_release_buf(), and reverting the flag if the call fails. This ensures no dereference occurs after potential freeing.
CVE-2026-46241 1 Linux 1 Linux Kernel 2026-06-10 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: fix use-after-free on registration failure Make sure to disable and free the interrupts in case controller registration fails to avoid a potential use-after-free and resource leak. This issue was flagged by Sashiko when reviewing a controller deregistration fix.
CVE-2026-45782 2026-06-10 N/A N/A
Cloud Hypervisor is a Virtual Machine Monitor for Cloud workloads. From version 21.0 to before version 51.2, a guest can cause a use-after-free in the cloud-hypervisor process by submitting two virtio-block descriptor chains that reuse the same head_index while asynchronous block I/O is enabled (e.g. io_uring, aio). When the kernel completes the duplicate operation before the original, the completion path frees a bounce buffer that the kernel is still actively reading from or writing to, corrupting the freed memory. This issue has been patched in versions 51.2 and 52.0.
CVE-2026-45657 1 Microsoft 6 Windows 11 23h2, Windows 11 24h2, Windows 11 25h2 and 3 more 2026-06-10 N/A 9.8 CRITICAL
Use after free in Windows Kernel allows an unauthorized attacker to execute code over a network.
CVE-2026-34335 1 Microsoft 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more 2026-06-10 N/A 7.0 HIGH
Use after free in Windows Ancillary Function Driver for WinSock allows an authorized attacker to elevate privileges locally.
CVE-2026-42978 1 Microsoft 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more 2026-06-10 N/A 7.8 HIGH
Concurrent execution using shared resource with improper synchronization ('race condition') in Windows Push Notifications allows an authorized attacker to elevate privileges locally.
CVE-2026-42984 1 Microsoft 10 Windows 10 1809, Windows 10 21h2, Windows 10 22h2 and 7 more 2026-06-10 N/A 7.0 HIGH
Use after free in Windows Kernel allows an authorized attacker to elevate privileges locally.
CVE-2026-48913 1 Apache 1 Http Server 2026-06-10 N/A 7.3 HIGH
Use After Free vulnerability in Apache HTTP Server module mod_http2 when file handles are already exhausted. This issue affects Apache HTTP Server: from 2.4.55 through 2.4.67.
CVE-2026-46210 1 Linux 1 Linux Kernel 2026-06-10 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: media: iris: fix use-after-free of fmt_src during MBPF check During concurrency testing, multiple instances can run in parallel, and each instance uses its own inst->lock while the core->lock protects the list of active instances. The race happens because these locks cover different scopes, inst->lock protects only the internals of a single instance, while the Macro Blocks Per Frame (MBPF) checker walks the core list under core->lock and reads fields like fmt_src->width and fmt_src->height. At the same time, iris_close() may free fmt_src and fmt_dst under inst->lock while the instance is still present in the core list. This allows a situation where the MBPF checker, still iterating through the core list, reaches an instance whose fmt_src was already freed by another thread and ends up dereferencing a dangling pointer, resulting in a use-after-free. This happens because the MBPF checker assumes that any instance in the core list is fully valid, but the freeing of fmt_src and fmt_dst without removing the instance from the core list is not correct. The correct ordering is to defer freeing fmt_src and fmt_dst until after the instance has been removed from the core list and all teardown under the core lock has completed, ensuring that no dangling pointers are ever exposed during MBPF checks.
CVE-2026-46212 1 Linux 1 Linux Kernel 2026-06-10 N/A 8.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: prevent use-after-free when deleting claims When batadv_bla_del_backbone_claims() removes all claims for a backbone, it does this by dropping the link entry in the hash list. This list entry itself was one of the references which need to be dropped at the same time via batadv_claim_put(). But the batadv_claim_put() must not be done before the last access to the claim object in this function. Otherwise the claim might be freed already by the batadv_claim_release() function before the list entry was dropped.
CVE-2026-46213 1 Linux 1 Linux Kernel 2026-06-10 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: HID: appletb-kbd: fix UAF in inactivity-timer cleanup path Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe") added timer_delete_sync(&kbd->inactivity_timer) to both the probe close_hw error path and appletb_kbd_remove(), but the way it was wired in left the inactivity timer reachable during driver tear-down via two distinct windows. Window A -- put_device() before timer_delete_sync(): put_device(&kbd->backlight_dev->dev); timer_delete_sync(&kbd->inactivity_timer); The inactivity_timer softirq reads kbd->backlight_dev and calls backlight_device_set_brightness() -> mutex_lock(&ops_lock). If a concurrent hid_appletb_bl unbind drops the last devm reference between these two calls, the backlight_device is freed and the mutex_lock() touches freed memory. Window B -- backlight cleanup before hid_hw_stop(): if (kbd->backlight_dev) { timer_delete_sync(...); put_device(...); } hid_hw_close(hdev); hid_hw_stop(hdev); Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run afterwards, so a late ".event" callback from the HID core (USB URB completion on real Apple hardware) can arrive after timer_delete_sync() drained the softirq but before put_device() drops the reference. That callback reaches reset_inactivity_timer(), which calls mod_timer() and re-arms the timer. The freshly re-armed timer can then fire on the about-to-be-freed backlight_device. Both windows produce the same KASAN slab-use-after-free: BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0 Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0 Call Trace: <IRQ> __mutex_lock backlight_device_set_brightness appletb_inactivity_timer call_timer_fn run_timer_softirq handle_softirqs Allocated by task N: devm_backlight_device_register appletb_bl_probe Freed by task M: (concurrent hid_appletb_bl unbind path) Close both windows at once by reworking the tear-down in appletb_kbd_remove() and in the probe close_hw error path so that 1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup, guaranteeing no further .event callback can fire and re-arm the timer, and 2) inside the "if (kbd->backlight_dev)" block, timer_delete_sync() runs before put_device(), so the softirq is drained before the final reference is dropped.
CVE-2026-46215 1 Linux 1 Linux Kernel 2026-06-10 N/A 7.8 HIGH
In the Linux kernel, the following vulnerability has been resolved: drm: Set old handle to NULL before prime swap in change_handle There was a potential race condition in change_handle. The ioctl briefly had a single object with two idr entries; a concurrent gem_close could delete the object and remove one of the handles while leaving the other one dangling, which could subsequently be dereferenced for a use-after-free. To fix this, do the same dance that gem_close itself does. (f6cd7daecff5 drm: Release driver references to handle before making it available again) First idr_replace the old handle to NULL. Later, if the prime operations are successful, actually close it. create_tail required a similar dance to avoid a similar problem. (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail()) It idr_allocs the new handle with NULL, then swaps in the correct object later to avoid races. We don't need to do that here, since the only operations that could race are drm_prime, and change_handle holds the prime lock for the entire duration. v2: cleanups of error paths
CVE-2026-11230 4 Apple, Google, Linux and 1 more 4 Macos, Chrome, Linux Kernel and 1 more 2026-06-10 N/A 8.8 HIGH
Use after free in Extensions in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Low)