本ページは linux linux_kernel に影響する公開済み CVE（NVD の CPE 経由で関連付け）を列挙します。各行に深刻度指標・概要・公開日が含まれます。
| CVE | 概要 | ソース | CVSS 最大値 | EPSS（%） | 公開 | 更新 |
|---|---|---|---|---|---|---|
| CVE-2026-53165 | 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 io | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.36% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53164 | 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 s | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53163 | 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_block | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53162 | 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 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53161 | 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 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53160 | 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_l | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.12% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53159 | 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 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53158 | 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_ir | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53157 | 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. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53156 | 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. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53155 | 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 insta | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53154 | 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_pu | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53153 | 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 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53152 | 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 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53151 | 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 pa | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.8 | 0.48% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53150 | 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 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.18% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53149 | 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. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.18% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53148 | 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 ex | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.18% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53147 | 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. P | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.1 | 0.28% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53146 | 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. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.1 | 0.18% | 2026-06-25 | 2026-06-28 |