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-53285 | In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs. The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_ | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.15% | 2026-06-26 | 2026-06-26 |
| CVE-2026-53284 | In the Linux kernel, the following vulnerability has been resolved: btrfs: only release the dirty pages io tree after successful writes [WARNING] With extra warning on dirty extent buffers at umount (aka, the next patch in the series), test case generic/388 can trigger the following warning about dirty extent buffers at unmount time: BTRFS critical (device dm-2 state E): emergency shutdown BTRFS error (device dm-2 state E): error while writing out transaction: -30 BTRFS warning (device | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.43% | 2026-06-26 | 2026-06-29 |
| CVE-2026-53283 | In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bounds-check devid in __rlookup_amd_iommu() iommu_device_register() walks every device on the PCI bus via bus_for_each_dev() and calls amd_iommu_probe_device() for each. The inlined check_device() path computes the device's sbdf, calls rlookup_amd_iommu() to find the owning IOMMU, and only afterwards verifies devid <= pci_seg->last_bdf. __rlookup_amd_iommu() indexes rlookup_table[devid] with no bounds check of its o | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-26 | 2026-06-26 |
| CVE-2026-53282 | In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Push kjump return address even for non-kjump kexec The version of purgatory code shipped by kexec-tools attempts to look above the top of its stack to find a return address for a kjump, even in a non-kjump kexec. After the commit in Fixes: the word above the stack might not be there, leading to a fault (which is at least now caught by my exception-handling code in kexec). That commit fixed things for the actual kj | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-26 | 2026-06-26 |
| CVE-2026-53281 | In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid NULL pointer dereference or refcount corruption Commit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") fixed a NULL pointer dereference in an unlikely situation partly. If dev_pasid is not found in the dev_pasids list, it remains NULL. However, the teardown operations are executed unconditionally, this lead to a NULL pointer dereference or refcount corruption. If the domain was never attac | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.12% | 2026-06-26 | 2026-06-28 |
| CVE-2026-53280 | In the Linux kernel, the following vulnerability has been resolved: iommu: Fix NULL group->domain dereference in pci_dev_reset_iommu_done() Local sashiko review pointed it out that group->domain could be NULL when a default domain fails to allocate during the first probe, which can crash at domain->ops->attach_dev dereference in __iommu_attach_device() invoked by pci_dev_reset_iommu_done(). pci_dev_reset_iommu_prepare() is fine as an old_domain pointer can be NULL. Skip the re-attach in pci_ | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.15% | 2026-06-26 | 2026-06-26 |
| CVE-2026-53279 | In the Linux kernel, the following vulnerability has been resolved: drm/gma500/oaktrail_lvds: fix hang on init failure The LVDS init code looks up an I2C adapter using i2c_get_adapter() and tries to read the EDID before falling back to allocating and registering its own adapter. The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2c_get_adapter() takes another reference to the | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-26 | 2026-06-26 |
| CVE-2026-53278 | In the Linux kernel, the following vulnerability has been resolved: arm_mpam: Check whether the config array is allocated before destroying it __destroy_component_cfg() is called to free the configuration array. It uses the embedded 'garbage' structure, which means the array has to be allocated. If __destroy_component_cfg() is called from mpam_disable() before the configuration was ever allocated, then a NULL pointer is dereferenced. Check for this case and return early if the configuration | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.15% | 2026-06-26 | 2026-06-26 |
| CVE-2026-53277 | In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation walk_s1() and kvm_walk_nested_s2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the respective walkers without taking kvm->srcu. Fix by acquiring kvm->srcu prior to the table walk in both instances. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.14% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53276 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer In iso_sock_rebind_bc(), the bis pointer is cached, then the socket lock is dropped: bis = iso_pi(sk)->conn->hcon; /* Release the socket before lookups since that requires hci_dev_lock * which shall not be acquired while holding sock_lock for proper * ordering. */ release_sock(sk); hci_dev_lock(bis->hdev); During the unlocked window, could a concurrent clo | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.12% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53275 | In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packe | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.25% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53274 | In the Linux kernel, the following vulnerability has been resolved: net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS A logic flaw in __smc_setsockopt() allows a local unprivileged user to cause a Denial of Service (DoS) by holding the socket lock indefinitely. The function __smc_setsockopt() calls copy_from_sockptr() while holding lock_sock(sk). By passing a userfaultfd-monitored memory page (or FUSE-backed memory on systems where unprivileged userfaultfd is disabled) as | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.18% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53273 | In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.13% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53272 | In the Linux kernel, the following vulnerability has been resolved: erofs: fix use-after-free on sbi->sync_decompress z_erofs_decompress_kickoff() can race with filesystem unmount, causing a use-after-free on sbi->sync_decompress. When I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff() to queue z_erofs_decompressqueue_work() asynchronously. Then, after all folios are unlocked, unmount workflow can proceed and sbi will be freed before accessing to sbi->sync_decompress. Thread ( | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.16% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53271 | In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers smb2_oplock_break_noti() and smb2_lease_break_noti() read opinfo->conn into a local with neither READ_ONCE() nor a NULL check. Both run from oplock_break() after opinfo_get_list() has dropped ci->m_lock, so a concurrent SMB2 LOGOFF (session_fd_check()) can set op->conn = NULL under ci->m_lock within that window. ksmbd_conn_r_count_inc(conn) then writes thr | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.16% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53270 | In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.13% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53269 | In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like S | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | — | 0.17% | 2026-06-25 | 2026-06-25 |
| CVE-2026-53268 | In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.2 | 0.36% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53267 | In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: bail out on template ct in get eval I noticed this issue while looking at a historic syzbot report [1]. A rule like the one below is enough to trigger the bug: table ip t { chain pre { type filter hook prerouting priority raw; ct zone set 1 ct original saddr 1.2.3.4 accept } } The first expression attaches a per-cpu template ct via nft_ct_set_zon | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.13% | 2026-06-25 | 2026-06-28 |
| CVE-2026-53266 | In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and wo | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.13% | 2026-06-25 | 2026-06-28 |