Linux 関連製品全体の CVE とセキュリティ脆弱性情報を集約し、CVSS、EPSS、公開日、脆弱性情報データを掲載しています。
一般的な弱点パターンには vendor risk memory corruption、バッファオーバーフロー、パス処理の欠陥, and vendor risk input validation があり、vendor surface server deployment and vendor surface system components の利用場面で アプリケーションクラッシュ、ファイル上書き, and vendor impact unexpected behavior などのリスクが生じる可能性があります。
掲載データは公開脆弱性情報とセキュリティ公告に基づき、過去の暴露面と修補優先度の評価に利用できます。
| CVE | 概要 | ソース | CVSS 最大値 | EPSS（%） | 公開 | 更新 |
|---|---|---|---|---|---|---|
| CVE-2026-53327 | In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-07-01 | 2026-07-14 |
| CVE-2026-53326 | In the Linux kernel, the following vulnerability has been resolved: debugobjects: Don't call fill_pool() in early boot hardirq context When booting a debug PREEMPT_RT kernel on an ARM64 system, a "inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage" lockdep warning message was reported to the console. During early boot, interrupts are enabled before the scheduler is enabled. In this window (before SYSTEM_SCHEDULING is set) interrupts can fire and in the hard interrupt context handler attempt | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-07-01 | 2026-07-14 |
| CVE-2026-53325 | In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northb | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.12% | 2026-06-29 | 2026-07-06 |
| CVE-2026-53324 | In the Linux kernel, the following vulnerability has been resolved: net: mana: Use pci_name() for debugfs directory naming Use pci_name(pdev) for the per-device debugfs directory instead of hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The previous approach had two issues: 1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs in environments like generic VFIO passthrough or nested KVM, causing a NULL pointer dereference. 2. Multiple PFs would all use "0", | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53323 | In the Linux kernel, the following vulnerability has been resolved: net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops DSA replaces the conduit (master) device's ethtool_ops with its own wrappers that aggregate stats from both the conduit and DSA switch ports. Taking the lock again inside the DSA wrappers causes a deadlock. Stumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y (which looks like some kind of testing device that auto-populates the ports of | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.09% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53322 | In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Clean up DMABUFs before disabling function On device shutdown, make vfio_pci_core_close_device() call vfio_pci_dma_buf_cleanup() before the function is disabled via vfio_pci_core_disable(). This ensures that all access via DMABUFs is revoked before the function's BARs become inaccessible. This fixes an issue where, if the function is disabled first, a tiny window exists in which the function's MSE is cleared and ye | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.17% | 2026-06-26 | 2026-07-14 |
| CVE-2026-53321 | In the Linux kernel, the following vulnerability has been resolved: io_uring/napi: cap busy_poll_to 10 msec Currently there's no cap on the maximum amount of time that napi is allowed to poll if no events are found, which can lead to kernel complaints on a task being stuck as there's no conditional rescheduling done within that loop. Just cap it to 10 msec in total, that's already way above any kind of sane value that will reap any benefits, yet low enough that it's nowhere near being able to | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53320 | In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr s | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.12% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53319 | In the Linux kernel, the following vulnerability has been resolved: blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from wbt_alloc() and wbt_init(). However, both are expected failure paths: - wbt_alloc() can return NULL under memory pressure (-ENOMEM) - wbt_init() can fail with -EBUSY if wbt is already registered syzbot triggers this by injecting memory allocation failures during MTD partition creation via ioctl(B | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.14% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53318 | In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr() Move the NULL check for 'sta' before dereferencing it to prevent a possible crash. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53317 | In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: Place upper limit on station AID Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds. In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd beg | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53316 | In the Linux kernel, the following vulnerability has been resolved: drm/amd/ras: Fix NULL deref in ras_core_ras_interrupt_detected() Fixes a NULL pointer dereference when ras_core is NULL and ras_core->dev is accessed in the error path. Reported by: Dan Carpenter <[email protected]> | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.14% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53315 | In the Linux kernel, the following vulnerability has been resolved: drm/amd/ras: Fix NULL deref in ras_core_get_utc_second_timestamp() ras_core_get_utc_second_timestamp() retrieves the current UTC timestamp (in seconds since the Unix epoch) through a platform-specific RAS system callback and is used for timestamping RAS error events. The function checks ras_core in the conditional statement before calling the sys_fn callback. However, when the condition fails, the function prints an error mes | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.15% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53314 | In the Linux kernel, the following vulnerability has been resolved: padata: Put CPU offline callback in ONLINE section to allow failure syzbot reported the following warning: DEAD callback error for CPU1 WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614 at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padata_cpu_dead() given it's the only sub-CPUHP | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53313 | In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Both functions check: if (!dc_dmub_srv || !dc_dmub_srv->dmub) and then call DC_LOG_ERROR() inside that block. DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash. Fix this by splitting the c | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.14% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53312 | In the Linux kernel, the following vulnerability has been resolved: iommu/riscv: Remove overflows on the invalidation path Since RISC-V supports a sign extended page table it should support a gather->end of ULONG_MAX, but if this happens it will infinite loop because of the overflow. Also avoid overflow computing the length by moving the +1 to the other side of the < | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53311 | In the Linux kernel, the following vulnerability has been resolved: fuse: fix uninit-value in fuse_dentry_revalidate() fuse_dentry_revalidate() may be called with a dentry that didn't had ->d_time initialised. The issue was found with KMSAN, where lookup_open() calls __d_alloc(), followed by d_revalidate(), as shown below: ===================================================== BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394 fuse_dentry_revalidate+0x150/0x13d | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53310 | In the Linux kernel, the following vulnerability has been resolved: soc/tegra: cbb: Fix cross-fabric target timeout lookup When a fabric receives an error interrupt, the error may have occurred on a different fabric. The target timeout lookup was using the wrong base address (cbb->regs) with offsets from a different fabric's target map, causing a kernel page fault. Unable to handle kernel paging request at virtual address ffff80000954cc00 pc : tegra234_cbb_get_tmo_slv+0xc/0x28 Call trac | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53309 | In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison The local-vs-remote region comparison loop uses '<=' instead of '<', causing it to read one entry past the valid range of qr_regions. The other loops in the same function correctly use '<'. Fix the loop condition to use '<' for consistency and correctness. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.8 | 0.40% | 2026-06-26 | 2026-07-06 |
| CVE-2026-53308 | In the Linux kernel, the following vulnerability has been resolved: power: supply: max77705: Free allocated workqueue and fix removal order Use devm interface for allocating workqueue to fix two bugs at the same time: 1. Driver leaks the memory on remove(), because the workqueue is not destroyed. 2. Driver allocates workqueue and then registers interrupt handlers with devm interface. This means that probe error paths will not use a reversed order, but first destroy the workqueue an | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.14% | 2026-06-26 | 2026-07-06 |