Vulnerability database

25,390 results · page 126 of 508

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_CVE-2026-53190 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix dma_fence refcount leak on error in virtio_gpu_dma_fence_wait() dma_fence_unwrap_for_each() internally calls dma_fence_unwrap_first() which does cursor->chain = dma_fence_get(head), taking an extra reference. On normal loop completion, dma_fence_unwrap_next() releases this via dma_fence_chain_walk() -> dma_fence_put(). When virtio_gpu_do_fence_wait() fails and the function returns early from inside the loop, the cursor->chain reference is never released. This is the only caller in the entire kernel that does an early return inside dma_fence_unwrap_for_each. Add dma_fence_put(itr.chain) before the early return.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updatCVE-2026-53189 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put().

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate the passed in fops for ib_get_ucaps() Sashiko pointed out it is not saCVE-2026-53188 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate the passed in fops for ib_get_ucaps() Sashiko pointed out it is not safe to rely only on the devt because char/block alias so if the user finds a block device with the same dev_t it can masquerade as a ucap cdev fd. Test the f_ops to only accept authentic cdevs.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate cpu_id against nr_cpu_ids in DMAH alloc The cpu_id attribute supplied CVE-2026-53187 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate cpu_id against nr_cpu_ids in DMAH alloc The cpu_id attribute supplied by user space through UVERBS_ATTR_ALLOC_DMAH_CPU_ID is passed directly to cpumask_test_cpu() without first verifying that the value is within the valid CPU range. Passing such untrusted data to cpumask_test_cpu() may lead to an out-of-bounds read of the underlying cpumask bitmap: the helper expands to a test_bit() that indexes the bitmap by cpu_id / BITS_PER_LONG with no bound check. In addition, on kernels built with CONFIG_DEBUG_PER_CPU_MAPS it trips the WARN_ON_ONCE() in cpumask_check(); combined with panic_on_warn this turns a bad user input into a machine reboot. Reject any cpu_id that is not smaller than nr_cpu_ids with -EINVAL before it is used. Reported by Smatch.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense dCVE-2026-53186 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.1

  In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or aCVE-2026-53185 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight. The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page. zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the write_partial counterpart was missed.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is rCVE-2026-53184 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

  In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: if (skb->dev) caller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Tra

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP CVE-2026-53183 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

  In the Linux kernel, the following vulnerability has been resolved: mptcp: allow subflow rcv wnd to shrink In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed CVE-2026-53182 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: reject oversized EMA RNR lists nl80211_parse_rnr_elems() stores the parsed element count in a u8-backed cfg80211_rnr_elems::cnt field and uses that count to size the flexible array allocation. Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches 255, before incrementing it again. This keeps the parser aligned with the data structure it fills and matches the existing bound check used by nl80211_parse_mbssid_elems().

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connectinCVE-2026-53181 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: timers/migration: Fix livelock in tmigr_handle_remote_up() tmigr_handle_remote_cpu() skipsCVE-2026-53180 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

  In the Linux kernel, the following vulnerability has been resolved: timers/migration: Fix livelock in tmigr_handle_remote_up() tmigr_handle_remote_cpu() skips timer_expire_remote() when cpu == smp_processor_id(), assuming the local softirq path already handled this CPU's timers. This assumption is wrong because jiffies can advance after the handling of the CPU's global timers in run_timer_base(BASE_GLOBAL) and before tmigr_handle_remote() evaluates the expiry times. As a consequence a timer which expires after the CPU local timer wheel advanced and becomes expired in the remote handling is ignored and the callback is never invoked and removed from the timer wheel. What's worse is that fetch_next_timer_interrupt_remote() keeps reporting it as expired, and the event is re-queued with expires == now on each iteration. The goto-again loop spins indefinitely. Fix this by calling timer_expire_remote() unconditionally. That's minimal overhead for the common case as __run_timer_base() returns immediately if there is nothing to expire in the local wheel. [ tglx: Amend change log and add a comment ]

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix buffer over-read in rtw_update_protection rtw_update_protection() CVE-2026-53179 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix buffer over-read in rtw_update_protection rtw_update_protection() is called with a pointer offset into the ies buffer but the full ie_length is passed, causing a potential buffer over-read.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction Add guards toCVE-2026-53178 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1

  In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction Add guards to ensure ie_length is large enough before subtracting fixed IE offsets to prevent unsigned integer underflow.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream PoCVE-2026-53177 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/CVE-2026-53176 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

  In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush On netns teardown, fqCVE-2026-53175 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

  In the Linux kernel, the following vulnerability has been resolved: inet: frags: fix use-after-free caused by the fqdir_pre_exit() flush On netns teardown, fqdir_pre_exit() walks the fqdir rhashtable and flushes every fragment queue that is not yet complete using inet_frag_queue_flush(). That helper frees all the skbs queued on the fragment queue but does not set INET_FRAG_COMPLETE, and leaves q->fragments_tail and q->last_run_head pointing at the freed skbs. The queue itself stays in the rhashtable. fqdir_pre_exit() first lowers high_thresh to 0 to stop new queue lookups, but it cannot stop a fragment that already obtained the queue through inet_frag_find() earlier and stalled just before taking the queue lock. Once that fragment resumes after the flush and takes the queue lock, it passes the INET_FRAG_COMPLETE check and then dereferences the freed fragments_tail. inet_frag_queue_insert() reads FRAG_CB() and ->len of that pointer and, on the append path, writes ->next_frag, causing a slab use-after-free. IPv6, nf_conntrack_reasm6 and 6lowpan reassembly share the same flush path and are affected as well. Reset rb_fragments, fragments_tail and last_run_head in inet_frag_queue_fl

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: ovl: keep err zero after successful ovl_cache_get() ovl_iterate_merged() stores PTR_ERR(caCVE-2026-53174 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: ovl: keep err zero after successful ovl_cache_get() ovl_iterate_merged() stores PTR_ERR(cache) in err before checking IS_ERR(cache). On success err holds the truncated cache pointer and can be returned as a bogus non-zero error. The syzbot reproducer reaches this through overlay-on-overlay readdir: getdents64 iterate_dir(outer overlay file) ovl_iterate_merged() ovl_cache_get() ovl_dir_read_merged() ovl_dir_read() iterate_dir(inner overlay file) ovl_iterate_merged() Only compute PTR_ERR(cache) on the error path.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate() The command streamCVE-2026-53173 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix OOB write in ethosu_gem_cmdstream_copy_and_validate() The command stream parsing loop increments the index variable a second time when a 64-bit command word is encountered (bit 14 set), but does not re-check the loop bound before writing the second word: for (i = 0; i < size / 4; i++) { bocmds[i] = cmds[0]; if (cmd & 0x4000) { i++; bocmds[i] = cmds[1]; /* unchecked */ } } The buffer bocmds is backed by a DMA allocation of exactly size bytes from drm_gem_dma_create(ddev, size), giving valid indices [0, size/4-1]. When i == size/4 - 1 on entry to an iteration and bit 14 of cmds[0] is set, bocmds[size/4-1] is written in bounds, i is then incremented to size/4, and bocmds[size/4] writes four bytes past the end of the allocation. Userspace controls both the buffer contents and the size argument via the ioctl, making this a userspace-triggerable heap out-of-bounds write. Fix by checking the incremented index against the buffer bound before the second write and returning -EINVAL if the buffer is too small to contain the extended command.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix IFM region index out-of-bounds in command stream parser NPU_SET_IFM_REGICVE-2026-53172 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix IFM region index out-of-bounds in command stream parser NPU_SET_IFM_REGION extracts the region index with param & 0x7f, giving a maximum value of 127. However region_size[] and output_region[] in struct ethosu_validated_cmdstream_info are both sized to NPU_BASEP_REGION_MAX (8), giving valid indices [0..7]. Every other region assignment in the same switch uses param & 0x7: NPU_SET_OFM_REGION: st.ofm.region = param & 0x7; NPU_SET_IFM2_REGION: st.ifm2.region = param & 0x7; NPU_SET_WEIGHT_REGION: st.weight[0].region = param & 0x7; NPU_SET_SCALE_REGION: st.scale[0].region = param & 0x7; The 0x7f mask on IFM is inconsistent and appears to be a typo. feat_matrix_length() and calc_sizes() use the region index directly as an array subscript into the kzalloc'd info struct: info->region_size[fm->region] = max(...); A userspace caller supplying NPU_SET_IFM_REGION with param > 7 causes a write up to 127*8 = 1016 bytes past the start of region_size[], corrupting adjacent kernel heap data. Fix by applying the same & 0x7 mask used by all other region assignments.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix arithmetic issues in dma_length() dma_length() derives DMA region usage CVE-2026-53171 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: fix arithmetic issues in dma_length() dma_length() derives DMA region usage from command stream values and updates region_size[]: len = ((len + stride[0]) * size0 + stride[1]) * size1 region_size[region] = max(..., len + dma->offset) Several arithmetic issues can corrupt the derived region size: - signed stride values may underflow when added to len - intermediate multiplications may overflow - len + dma->offset may overflow during region_size updates - dma_length() error returns were not validated by the caller region_size[] is later used by ethosu_job.c to validate command stream accesses against GEM buffer sizes. Arithmetic wraparound can therefore under-report region usage and bypass the bounds validation. Fix by validating signed additions, using overflow helpers for multiplications and offset updates, and propagating dma_length() failures to the caller.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: reject DMA commands with uninitialized length cmd_state_init() initializes tCVE-2026-53170 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: reject DMA commands with uninitialized length cmd_state_init() initializes the command state with memset(0xff), leaving dma->len at U64_MAX to signal missing setup. The only setter is NPU_SET_DMA0_LEN; if userspace omits this command and issues NPU_OP_DMA_START, dma->len remains U64_MAX. In dma_length(), a positive stride added to U64_MAX wraps to a small value. With size0 == 1, check_mul_overflow() does not trigger and dma_length() returns 0 instead of U64_MAX. The caller's U64_MAX check then passes, region_size[] stays 0, and the bounds check in ethosu_job.c is bypassed, allowing hardware to execute DMA with stale physical addresses. Fix by checking for U64_MAX at the start of dma_length() before any arithmetic, consistent with the sentinel value used throughout the driver to detect uninitialized fields.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: reject NPU_OP_RESIZE commands from userspace NPU_OP_RESIZE is a U85-only comCVE-2026-53169 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: accel/ethosu: reject NPU_OP_RESIZE commands from userspace NPU_OP_RESIZE is a U85-only command that the driver does not yet implement. The existing WARN_ON(1) placeholder fires unconditionally whenever userspace submits this command via DRM_IOCTL_ETHOSU_GEM_CREATE, causing unbounded kernel log spam. If panic_on_warn is set the kernel panics, giving any unprivileged user with access to the DRM device a trivial denial-of-service primitive. Replace the WARN_ON(1) with an explicit -EINVAL return so the ioctl rejects the command before it reaches hardware.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE aCVE-2026-53168 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited tCVE-2026-53167 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: iomap: avoid potential null folio->mapping deref during error reporting When a buffered reCVE-2026-53165 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5

  In the Linux kernel, the following vulnerability has been resolved: iomap: avoid potential null folio->mapping deref during error reporting When a buffered read fails, iomap_finish_folio_read() reports the error with fserror_report_io(folio->mapping->host, ...). This is called after ifs->read_bytes_pending has been decremented by the bytes attempted to be read. For a folio split across multiple read completions, the folio is only guaranteed to stay locked while read_bytes_pending > 0. Once iomap_finish_folio_read() decrements read_bytes_pending, another in-flight read can complete and end the read on the folio, which unlocks it. This allows truncate logic to run and detach the folio (set folio->mapping to NULL). The error reporting path then can dereference a NULL folio->mapping. As reported by Sam Sun, this is the race that can occur: CPU0: failed completion CPU1: final completion CPU2: truncate ----------------------- ---------------------- -------------- read_bytes_pending -= len finished = false /* preempted before fserror_report_io() */ read_bytes_pending -= len finished = true folio_end_read() truncate clears foli

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Do not try to iommu_map a 0 length region in swiotlb iommu_dma_iova_link_swiotlCVE-2026-53164 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: iommu/dma: Do not try to iommu_map a 0 length region in swiotlb iommu_dma_iova_link_swiotlb() processes a mapping that is unaligned in three parts, the head, middle and trailer. If the middle is empty because there are no aligned pages it will call down to iommu_map() with a 0 size which the iommupt implementation will fail as illegal. It then tries to do an error unwind and starts from the wrong spot corrupting the mapping so the eventual destruction triggers a WARN_ON. Check for 0 length and avoid mapping and use offset not 0 as the starting point to unlink. This is frequently triggered by using some kinds of thunderbolt NVMe drives that trigger forced SWIOTLB for unaligned memory. NVMe seems to pass in oddly aligned buffers for the passthrough commands from smartctl that hit this condition.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the folCVE-2026-53163 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: memcg: use round-robin victim selection in refill_stock Harry Yoo reported that get_randomCVE-2026-53162 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: memcg: use round-robin victim selection in refill_stock Harry Yoo reported that get_random_u32_below() is not safe to call in the nmi context and memcg charge draining can happen in nmi context. More specifically get_random_u32_below() is neither reentrant- nor NMI-safe: it acquires a per-cpu local_lock via local_lock_irqsave() on the batched_entropy_u32 state. An NMI that lands on a CPU mid-update of the ChaCha batch state and recurses into the random subsystem would corrupt that state. The memcg_stock local_trylock prevents re-entry on the percpu stock itself, but cannot protect an unrelated subsystem's per-cpu lock. Replace the random pick with a per-cpu round-robin counter stored in memcg_stock_pcp and serialized by the same local_trylock that already guards cached[] and nr_pages[]. No atomics, no random calls, no extra locks needed.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race betCVE-2026-53161 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a CVE-2026-53160 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free race in fastrpc_map_create fastrpc_map_lookup returns a raw pointer after releasing fl->lock. The caller fastrpc_map_create then calls fastrpc_map_get (kref_get_unless_zero) on this unprotected pointer. A concurrent MEM_UNMAP can free the map between the lock release and the kref operation, resulting in a use-after-free on the freed slab object. Restore the take_ref parameter to fastrpc_map_lookup so the reference is acquired atomically under fl->lock before the pointer is exposed to the caller.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses fCVE-2026-53159 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8

  In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference wCVE-2026-53158 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a pCVE-2026-53157 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths iCVE-2026-53156 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: nvmem: core: fix use-after-free bugs in error paths Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: use correct flags for device private PMD entry Commit 65edfda6f3f2 ("mm/rmCVE-2026-53155 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: use correct flags for device private PMD entry Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") updated set_pmd_migration_entry() to use pmdp_huge_get_and_clear() in the softleaf case, but made no further adjustments to the function itself. Therefore this function continues to incorrectly use pmd_write(), pmd_soft_dirty() and pmd_uffd_wp() to determine whether the installed migration entry should be marked writable, softdirty or uffd-wp respectively. Whilst all are incorrect, the most problematic of these is pmd_write(), as this can lead to corrupted rmap state. On x86-64 _PAGE_SWP_SOFT_DIRTY is aliased to _PAGE_RW. So calling pmd_write() on a softleaf will return the softdirty state encoded in the entry, assuming CONFIG_MEM_SOFT_DIRTY was enabled. This was observed when running the hmm.hmm_device_private.anon_write_child selftest: 1. The test faults in a range then migrates it such that a device-private THP range is established. 2. The parent then migrates it to a device-private writable PMD entry whose folio is entirely AnonExclusive with ent

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetCVE-2026-53154 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: restore reservation on error in hugetlb folio copy paths Two sites in mm/hugetlb.c allocate a hugetlb folio via alloc_hugetlb_folio() (consuming a VMA reservation) and then call copy_user_large_folio(), which became int-returning in commit 1cb9dc4b475c ("mm: hwpoison: support recovery from HugePage copy-on-write faults") and can now fail (e.g. -EHWPOISON on a hwpoisoned source page). On the failure path, folio_put() restores the global hugetlb pool count through free_huge_folio(), but the per-VMA reservation map entry is left marked consumed: - hugetlb_mfill_atomic_pte() resubmission path (UFFDIO_COPY) - copy_hugetlb_page_range() fork-time CoW path when hugetlb_try_dup_anon_rmap() fails (rare: pinned hugetlb anon folio under fork) User-visible effect: on UFFDIO_COPY into a private hugetlb VMA where the resubmission copy fails, the reservation for that address is leaked from the VMA's reserve map. A subsequent fault at the same address takes the no-reservation path, and under hugetlb pool pressure the task is SIGBUSed at an address it had previously reserved. The fork-time CoW path le

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: mm/list_lru: drain before clearing xarray entry on reparent memcg_reparent_list_lrus() cleCVE-2026-53153 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: mm/list_lru: drain before clearing xarray entry on reparent memcg_reparent_list_lrus() clears the dying memcg's xarray entry with xas_store(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent list_lru_del() arriving for the dying memcg sees xa_load() == NULL, walks to the parent in lock_list_lru_of_memcg(), takes the parent's per-node lock, and calls list_del_init() on an item still physically linked on the dying memcg's list. If another in-flight thread holds the dying memcg's per-node lock at the same moment (another list_lru_del, or a list_lru_walk_one running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links. Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent list_lru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and walks to the parent, where the items now live.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: mmc: dw_mmc-rockchip: Add missing private data for very old controllers The really old conCVE-2026-53152 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: mmc: dw_mmc-rockchip: Add missing private data for very old controllers The really old controllers (rk2928, rk3066, rk3188) do not support UHS speeds at all, and thus never handled phase data. For that reason it never had a parse_dt callback and no driver private data at all. Commit ff6f0286c896 ("mmc: dw_mmc-rockchip: Add memory clock auto-gating support") makes the private data sort of mandatory, because the init function checks whether phases are configured internally or through the clock controller. This results in the old SoCs then experiencing NULL-pointer dereferences when they try to access that private-data struct. While we could have if (priv) conditionals in all places, it's way less cluttery to just give the old types their private-data struct.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix the ACK parser to extract the SACK table for parsing Fix modification of the reCVE-2026-53151 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8

  In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix the ACK parser to extract the SACK table for parsing Fix modification of the received skbuff in rxrpc_input_soft_acks() and a potential incorrect access of the buffer in a fragmented UDP packet (the packet would probably have to be deliberately pre-generated as fragmented) when AF_RXRPC tries to extract the contents of the SACK table by copying out the contents of the SACK table into a buffer before attempting to parse AF_RXRPC assumes that it can just call skb_condense() and then validly access the SACK table from skb->data and that it will be a flat buffer - but skb_condense() can silently fail to do anything under some circumstances. Note that whilst rxrpc_input_soft_acks() should be able to parse extended ACKs, the rest of AF_RXRPC doesn't currently support that. Further, there's then no need to call skb_condense() in rxrpc_input_ack(), so don't.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() acCVE-2026-53150 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does notCVE-2026-53149 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_requestCVE-2026-53148 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request()CVE-2026-53147 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1

  In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Validate XDomain request packet size before type cast tb_xdp_handle_request() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation. Plumb the packet length through xdomain_request_work and validate it against the expected struct size before each cast.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies reqCVE-2026-53146 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1

  In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/gem: Try to fix change_handle ioctl, attempt 4 [airlied: just added some comments on hCVE-2026-53145 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: drm/gem: Try to fix change_handle ioctl, attempt 4 [airlied: just added some comments on how to reenable] On-list because the cat is out of the bag and we're clearly not good enough to figure this out in private. The story thus far: 5e28b7b94408 ("drm: Set old handle to NULL before prime swap in change_handle") tried to fix a race condition between the gem_close and gem_change_handle ioctls, but got a few things wrong: - There's a confusion with the local variable handle, which is actually the new handle, and so the two-stage trick was actually applied to the wrong idr slot. 7164d78559b0 ("drm/gem: fix race between change_handle and handle_delete") tried to fix that by adding yet another code block, but forgot to add the error handling. Which meant we now have two paths, both kinda wrong. - dc366607c41c ("drm: Replace old pointer to new idr") tried to apply another fix, but inconsistently, again because of the handle confusion - this would be the right fix (kinda, somewhat, it's a mess) if we'd do the two-stage approach for the new handle. Except that wasn't the intent of the original fix. W

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and nuCVE-2026-53144 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix NULL dereference in get_queue_ids() When usr_queue_id_array is NULL and num_queues is non-zero, get_queue_ids() returns NULL. The callers check only IS_ERR() on the return value; since IS_ERR(NULL) == false the check passes, and suspend_queues() calls q_array_invalidate() which immediately dereferences NULL while iterating num_queues times. Userspace can trigger this via kfd_ioctl_set_debug_trap() by supplying num_queues > 0 with a zero queue_array_ptr, causing a kernel panic. A NULL usr_queue_id_array with num_queues == 0 is a legitimate no-op (q_array_invalidate never executes, and resume_queues already guards all queue_ids dereferences behind a NULL check). Return ERR_PTR(-EINVAL) only when num_queues is non-zero and the pointer is absent; both callers already propagate IS_ERR() returns correctly to userspace. (cherry picked from commit f165a82cdf503884bb1797771c61b2fcc72113d4)

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manaCVE-2026-53143 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8

  In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11 The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow. During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer, leaking 1536 bytes of adjacent GTT memory to userspace During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer, corrupting 1536 bytes of adjacent GTT memory (often the ring buffer or neighboring MQDs) This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants. Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers. (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/xe/display: fix oops in suspend/shutdown without display The xe driver keeps track of CVE-2026-53142 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: drm/xe/display: fix oops in suspend/shutdown without display The xe driver keeps track of whether to probe display, and whether display hardware is there, using xe->info.probe_display. It gets set to false if there's no display after intel_display_device_probe(). However, the display may also be disabled via fuses, detected at a later time in intel_display_device_info_runtime_init(). In this case, the xe driver does for_each_intel_crtc() on uninitialized mode config in xe_display_flush_cleanup_work(), leading to a NULL pointer dereference, and generally calls display code with display info cleared. Check for intel_display_device_present() after intel_display_device_info_runtime_init(), and reset xe->info.probe_display as necessary. Also do unset_display_features() for completeness, although display runtime init has already done that. This will need to be unified across all cases later. Move intel_display_device_info_runtime_init() call slightly earlier, similar to i915, to avoid a bunch of unnecessary setup for no display cases. Note #1: The xe driver has no business doing low level display plumbing like for_

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix global performance monitor reference counting In the SET_GLOBAL ioctl, v3d_peCVE-2026-53141 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix global performance monitor reference counting In the SET_GLOBAL ioctl, v3d_perfmon_find() bumps the reference count on the perfmon it returns, but v3d_perfmon_set_global_ioctl() and v3d_perfmon_delete() fail to release that reference on several paths: 1. v3d_perfmon_set_global_ioctl() leaks the reference on its error paths. 2. CLEAR_GLOBAL leaks both the find reference and the reference previously stashed in v3d->global_perfmon by the SET_GLOBAL ioctl that configured it. 3. Destroying a perfmon that is the current global perfmon leaks the reference stashed by the SET_GLOBAL ioctl. Release each of these references explicitly.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

• Jun 25, 2026In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_couCVE-2026-53140 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 5.5

  In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix vaddr leak when indirect CSD has zeroed workgroups v3d_rewrite_csd_job_wg_counts_from_indirect() maps both the indirect buffer and the workgroup buffer and is expected to release them before returning. When any of the workgroup counts read from the buffer is zero, the function bailed out early and skipped the cleanup, leaking the vaddr mappings of both BOs. Jump to the cleanup path instead of returning directly, so the mappings are always dropped.

  Product

  Linux

  What to do

  Apply the vendor’s update. The NVD record links to the advisory.

  Full record and what to do →NVD recordgit.kernel.orggit.kernel.org

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.