本ページは linux linux_kernel に影響する公開済み CVE（NVD の CPE 経由で関連付け）を列挙します。各行に深刻度指標・概要・公開日が含まれます。
| CVE | 概要 | ソース | CVSS 最大値 | EPSS（%） | 公開 | 更新 |
|---|---|---|---|---|---|---|
| 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-30 |
| 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-30 |
| 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-30 |
| 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-30 |
| 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-30 |
| 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-30 |
| 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-30 |
| 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-30 |
| 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-30 |
| 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-30 |
| 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 | 7.0 | 0.14% | 2026-06-25 | 2026-06-30 |
| 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-30 |
| 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-30 |
| CVE-2026-53145 | 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: - The | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53144 | 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 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53143 | 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 byt | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.0 | 0.13% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53142 | 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_ | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53141 | 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 | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53140 | 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, | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-30 |
| CVE-2026-53139 | In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the d | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-30 |