Base de CVEs

CVE-2026-52973 Alta · 7.8 CWE-416 24/06/2026

futex: Drop CLONE_THREAD requirement for private default hash alloc

In the Linux kernel, the following vulnerability has been resolved: futex: Drop CLONE_THREAD requirement for private default hash alloc Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie: BUG: KASAN: slab-use-after-free in futex_hash_put ... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at. Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM.

CVE-2026-52971 Alta · 7.8 CWE-416 24/06/2026

net: ena: PHC: Fix potential use-after-free in get_timestamp

In the Linux kernel, the following vulnerability has been resolved: net: ena: PHC: Fix potential use-after-free in get_timestamp Move the phc->active check and resp pointer assignment to after acquiring the spinlock. Previously, phc->active was checked without holding the lock, and resp was cached from ena_dev->phc.virt_addr before the lock was acquired. If ena_com_phc_destroy() runs between the lockless active check and the lock acquisition, it sets active=false, releases the lock, frees the DMA memory, and sets virt_addr=NULL. The get_timestamp path would then read a NULL virt_addr and dereference it. With both the active check and the pointer read under the lock, destroy cannot free the memory while get_timestamp is using it.

CVE-2026-52951 Alta · 7.8 CWE-416 24/06/2026

drm/xe/dma-buf: handle empty bo and UAF races

In the Linux kernel, the following vulnerability has been resolved: drm/xe/dma-buf: handle empty bo and UAF races There look to be some nasty races here when triggering the invalidate_mappings hook: 1) We do xe_bo_alloc() followed by the attach, before the actual full bo init step in xe_dma_buf_init_obj(). However the bo is visible on the attachments list after the attach. This is bad since exporter driver, say amdgpu, can at any time call back into our invalidate_mappings hook, with an empty/bogus bo, leading to potential bugs/crashes. 2) Similar to 1) but here we get a UAF, when the invalidate_mappings hook is triggered. For example, we get as far as xe_bo_init_locked() but this fails in some way. But here the bo will be freed on error, but we still have it attached from dma-buf pov, so if the invalidate_mappings is now triggered then the bo we access is gone and we trigger UAF and more bugs/crashes. To fix this, move the attach step until after we actually have a fully set up buffer object. Note that the bo is not published to userspace until later, so not sure what the comment "Don't publish the bo until we have a valid attachment", is referring to. We have at least two different customers reporting hitting a NULL ptr deref in evict_flags when importing something from amdgpu, followed by triggering the evict flow. Hit rate is also pretty low, which would hint at some kind of race, so something like 1) or 2) might explain this. v2: - Shuffle the order of the ops slightly (no functional change) - Improve the comment to better explain the ordering (Matt B) (cherry picked from commit af1f2ad0c59fe4e2f924c526f66e968289d77971)

CVE-2026-52950 Alta · 7.8 CWE-416 24/06/2026

drm/xe/dma-buf: fix UAF with retry loop

In the Linux kernel, the following vulnerability has been resolved: drm/xe/dma-buf: fix UAF with retry loop Retry doesn't work here, since bo will be freed on error, leading to UAF. However, now that we do the alloc & init before the attach, we can now combine this as one unit and have the init do the alloc for us. This should make the retry safe. Reported by Sashiko. v2: Fix up the error unwind (CI) (cherry picked from commit 479669418253e0f27f8cf5db01a731352ea592e7)

CVE-2026-52947 Alta · 7.8 CWE-416 24/06/2026

net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: <TASK> qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... </TASK> Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)

CVE-2026-52943 Alta · 7.8 CWE-416 24/06/2026

net: skbuff: fix missing zerocopy reference in pskb_carve helpers

In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().

CVE-2026-52924 Crítica · 9.8 CWE-416 24/06/2026

Use-after-free no SCTP do kernel Linux ao tratar COOKIE-ECHO obsoleto

No kernel Linux, a seguinte vulnerabilidade foi resolvida: sctp: descarta a outqueue ao tratar COOKIE-ECHO obsoleto sctp_stream_update() só é invocada quando a associação é movida para COOKIE_WAIT durante a configuração ou reconfiguração da associação. Nesse caminho, espera-se que o estado do escalonador de streams de saída (stream->out_curr) esteja limpo, pois nenhum dado de usuário deveria ter sido transmitido ainda, a menos que a máquina de estados já tenha avançado parcialmente. No entanto, existe um caso particular em sctp_sf_do_5_2_6_stale(): quando um erro Stale Cookie é recebido, a associação é revertida de COOKIE_ECHOED para COOKIE_WAIT. Nesse cenário, dados de usuário podem já ter sido enfileirados e até agrupados com o chunk COOKIE-ECHO. Durante a reversão, sctp_stream_update() libera a tabela antiga de streams e instala uma nova, mas não invalida stream->out_curr. Como resultado, out_curr pode ainda apontar para uma entrada sctp_stream_out já liberada do estado anterior de streams. Posteriormente, os caminhos de desenfileiramento do escalonador SCTP (FCFS, RR, PRIO, etc.) dependem de stream->out_curr->ext, o que pode levar a use-after-free quando o estado antigo de streams já foi liberado por sctp_stream_free(). Isso resulta em travamentos como (relatado por Yuqi): BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140 Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312 CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted 7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full) sctp_sched_fcfs_dequeue+0x13a/0x140 sctp_outq_flush+0x1603/0x33e0 sctp_do_sm+0x31c9/0x5d30 sctp_assoc_bh_rcv+0x392/0x6f0 sctp_inq_push+0x1db/0x270 sctp_rcv+0x138d/0x3c10 Corrija isso purgando completamente a outqueue da associação ao tratar o caso de Stale Cookie. Isso garante que todo o estado pendente de transmissão e retransmissão seja descartado e que quaisquer ponteiros em cache do escalonador sejam invalidados, tornando seguro reconstruir o estado de streams durante o reinício em COOKIE_WAIT. Atualizar apenas stream->out_curr seria insuficiente, pois dados enfileirados e retransmissíveis ainda referenciariam o estado antigo de streams e causariam use-after-free posteriormente nos caminhos de desenfileiramento.

CVE-2026-52912 Alta · 7.8 CWE-416 24/06/2026

netfilter: nf_queue: hold bridge skb->dev while queued

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_queue: hold bridge skb->dev while queued br_pass_frame_up() rewrites skb->dev from the ingress port to the bridge master before queueing bridge LOCAL_IN packets. NFQUEUE only holds references on state.in/out and bridge physdevs, so a queued bridge packet can retain a freed bridge master in skb->dev until reinjection. When the verdict is reinjected later, br_netif_receive_skb() re-enters the receive path with skb->dev still pointing at the freed bridge master, triggering a use-after-free. Store skb->dev in the queue entry, hold a reference on it for the queue lifetime, and use the saved device when dropping queued packets during NETDEV_DOWN handling.

CVE-2026-56117 Média · 5.5 CWE-416 23/06/2026

dhcpcd Heap Use-After-Free via Control Socket Handling

dhcpcd through 10.3.2, fixed in commit 78ea09e, contains a heap use-after-free vulnerability in the control socket handling within src/control.c that allows local unprivileged attackers to trigger memory corruption when privilege separation is disabled. Attackers can connect to the control socket and send a privileged command such as -x, causing control_recvdata() to free the client object while the same READ+HANGUP event subsequently reaches control_hangup() with the stale pointer, resulting in a use-after-free condition exploitable in deployments using --disable-privsep or where privsep initialization has failed with the control socket operating in mode 0666.

CVE-2026-56113 Média · 6.5 CWE-416 23/06/2026

dhcpcd Heap Use-After-Free in dhcp6_deprecateaddrs via DHCPv6 RENEW

dhcpcd through 10.3.2, fixed in commit 5733d3c, contains a heap use-after-free vulnerability that allows unauthenticated same-link attackers to crash the daemon by sending a crafted DHCPv6 RENEW reply with RFC6603 OPTION_PD_EXCLUDE and both preferred and valid lifetimes set to zero. Attackers acting as or impersonating a DHCPv6 server can trigger dhcp6_deprecatedele() to free a delegated child address while an outer TAILQ_FOREACH_SAFE iterator in dhcp6_deprecateaddrs() still holds the freed pointer, causing a use-after-free when TAILQ_REMOVE is reached.

CVE-2026-56376 Baixa · 3.3 CWE-416 23/06/2026

ImageMagick - Heap Use-After-Free in Meta Coder

ImageMagick before 7.1.2-15 and 6.9.13-40 contains a heap use-after-free in the meta coder: when memory allocation fails, a single byte is written to a stale pointer. Remote attackers can trigger it by processing specially crafted image files, causing a denial of service.

CVE-2026-6653 Crítica · 9.8 CWE-416 22/06/2026

Use-After-Free em xmlParseInternalSubset do libxml2 Causando Negação de Serviço

Use After Free em xmlParseInternalSubset da libxml2 da GNOME, na versão 2.9.11 até 2.11.0, permite que um atacante remoto cause negação de serviço por meio de entrada XML maliciosamente elaborada, com tratamento inadequado de resolução de entidades.

CVE-2026-56412 Média · 5.9 CWE-416 21/06/2026

libexpat before 2.8.2 does not consider XML_TOK_DATA_CHARS in doCdataSection and thus lacks...

libexpat before 2.8.2 does not consider XML_TOK_DATA_CHARS in doCdataSection and thus lacks handler call depth tracking for various calls from within handlers in cases of a policy violation. Thus, a use-after-free can occur. NOTE: this issue exists because of an incomplete fix for CVE-2026-50219.

CVE-2026-12706 Média · 6.5 CWE-416 19/06/2026

Ffmpeg: ffmpeg: heap use-after-free read in rasc decoder decode_move()

A use-after-free vulnerability was found in FFmpeg's RASC video decoder. The decode_move() function initializes a read pointer into a decompressed buffer, but a subsequent reallocation of that same buffer during move-table processing leaves the pointer dangling. An attacker could exploit this by providing a specially crafted AVI file containing a malicious RASC video stream. When a user opens or plays the file, the decoder reads from freed heap memory, which could lead to a denial of service (crash).

CVE-2026-11941 Média · 5.6 CWE-416 19/06/2026

Use-after-free in connection ID iterator and FFI functions

Cloudflare Quiche was affected by 2 use-after-free vulnerabilities in the connection ID iterator FFI functions. The “quiche_connection_id_iter_next” and “quiche_conn_retired_scid_next” functions would return a pointer to a “ConnectionId” to the applications via function arguments, but the owned “ConnectionId” would be dropped at the end of those functions' scope. Only applications using those FFI functions are affected. The FFI API is disabled by default by a build-time feature flag. Impact If unpatched, an application calling the affected FFI functions will dereference freed memory. The most likely outcome is undefined behavior leading to a process crash (denial of service). Depending on allocator state, the read may also return adjacent heap contents, resulting in limited information disclosure or incorrect connection identifier handling. Mitigation Users are requested to upgrade to quiche 0.29.2 which is the earliest version containing the fix for this issue.

CVE-2026-41156 Alta · 7.7 CWE-416 19/06/2026

GPU DDK - kernel<->fw CCB contains SYNC_PRIMITIVE_BLOCK firmware address without holding reference

Software installed and run as a non-privileged user may conduct improper GPU system calls to cause mismanagement of resources creating a write use after free scenario. A shared resource (memory page) managed by a CPU thread of control (driver) and accessed by a GPU thread of control (Firmware) can cause a write UAF when the CPU thread frees the resource before the GPU FW has finished accessing it.

CVE-2026-34192 Alta · 7.7 CWE-416 19/06/2026

GPU DDK - _MMU_AllocLevel error recovery paths leave dangling page table entries

Software installed and run as a non-privileged user may conduct improper GPU system calls to cause an error path leading to UAF of GPU page tables. The vulnerability allows physical memory allocated for MMU page tables to be used after being freed. This was caused by an error path that would not cleanup properly before freeing the physical allocation.

CVE-2026-56131 Média · 4.9 CWE-416 19/06/2026

libexpat before 2.8.2 lacks handler call depth tracking for calls to XML_ResumeParser from within...

libexpat before 2.8.2 lacks handler call depth tracking for calls to XML_ResumeParser from within handlers in cases of a policy violation. Thus, a use-after-free can occur (similar to the CVE-2026-50219 situation).

CVE-2026-11791 Média · 5.0 CWE-416 18/06/2026

389-ds-base: 389-ds-base: use-after-free in schema reload via attr_syntax_swap_ht()

A flaw was found in 389 Directory Server. During schema reload, the attr_syntax_swap_ht() function unconditionally frees attribute syntax information nodes, bypassing the refcount-based deferred deletion used elsewhere in the attribute syntax subsystem. If an administrator triggers schema reload while concurrent LDAP query traffic is active, worker threads may access freed memory, resulting in use-after-free or double-free and a denial of service (server crash).

CVE-2026-9158 Crítica · 9.8 CWE-416 18/06/2026

Eclipse 4diac FORTE: use-after-free via comando DELETE de conexão manipulado

No Eclipse 4diac FORTE, versões 3.0.0 a 3.1.0, um comando DELETE de conexão especialmente elaborado enviado à interface de gerenciamento pode levar a um ponteiro pendente (dangling pointer). Isso permite que comandos subsequentes acessem memória liberada (use-after-free).

CVE-2026-42530 Alta · 8.1 CWE-416 17/06/2026

NGINX Open-Source ngx_http_v3_module vulnerability

NGINX Open Source has a vulnerability in the ngx_http_v3_module module. When NGINX Open Source is configured to use the HTTP/3 QUIC module, a remote unauthenticated attacker along with conditions beyond their control can use a specially crafted HTTP/3 session to reopen a QPACK encoder stream. This may cause a Use-after-Free in the NGINX worker process leading to a restart. Additionally, attackers can execute code on systems with Address Space Layout Randomization (ASLR) disabled or when the attacker can bypass ASLR. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

CVE-2026-12467 Alta · 8.3 CWE-416 17/06/2026

Use after free in Extensions in Google Chrome prior to 149.0.7827.155 allowed a remote attacker...

Use after free in Extensions in Google Chrome prior to 149.0.7827.155 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

CVE-2026-12464 Alta · 8.3 CWE-416 17/06/2026

Use after free in Browser in Google Chrome prior to 149.0.7827.155 allowed a remote attacker who...

Use after free in Browser in Google Chrome prior to 149.0.7827.155 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

CVE-2026-12462 Alta · 7.5 CWE-416 17/06/2026

Use after free in Media in Google Chrome prior to 149.0.7827.155 allowed a remote attacker who...

Use after free in Media in Google Chrome prior to 149.0.7827.155 allowed a remote attacker who had compromised the renderer process to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

CVE-2026-12455 Alta · 7.5 CWE-416 17/06/2026

Use after free in Tab Strip in Google Chrome prior to 149.0.7827.155 allowed a remote attacker...

Use after free in Tab Strip in Google Chrome prior to 149.0.7827.155 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)