Aggregates CVE and security vulnerability intelligence across all Linux-related products, including CVSS, EPSS, publication dates, and vulnerability intelligence data.
Historical issues mainly involve vendor risk memory corruption, vendor risk buffer overflow, vendor risk path handling, and vendor risk input validation and related problems; some flaws may lead to vendor impact application crash.
| CVE | Summary | Source | Max CVSS | EPSS % | Published | Updated |
|---|---|---|---|---|---|---|
| CVE-2026-53226 | In the Linux kernel, the following vulnerability has been resolved: gpio: rockchip: fix generic IRQ chip leak on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe. However, on driver remove/teardown, the generic chips are not automatically freed when the IRQ domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Ad | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.12% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53225 | In the Linux kernel, the following vulnerability has been resolved: sctp: fix uninit-value in __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF chunk can hold the ADDIP header and a parameter header, then calls af->from_addr_param(), which reads the full address (16 bytes for IPv6) trusting the parameter's declared length. An unauthenticated peer can send a truncated trailing ASCONF chunk that declares an IPv6 address parameter but stops aft | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.1 | 0.54% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53224 | In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded INIT chunk and address list lengths in cookie sctp_unpack_cookie() only checked that the embedded INIT chunk length did not exceed the remaining cookie payload, but did not ensure that the INIT chunk is large enough to contain a complete INIT header. A malformed COOKIE_ECHO can therefore carry a truncated INIT chunk whose length field is smaller than sizeof(struct sctp_init_chunk). Later, sctp_process | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.1 | 0.55% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53223 | In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the gen | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.1 | 0.13% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53222 | In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: fix resource freeing order Commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events") added a call to ptp_disable_all_events() which changes the configuration of pins if they support EXTTS events. In ptp_ocp_detach() pins resources are freed before ptp_clock_unregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53221 | In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the sam | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.8 | 0.56% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53220 | In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53219 | In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the in | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53218 | In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining unini | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53217 | In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.6 | 0.40% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53216 | In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, cor | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.8 | 0.55% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53215 | In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. That is only valid while the driver still owns the buffer. mvpp2_rx_refill() can fail after the current buffer has been handed to XDP or attached to an skb. In those cases mvpp2_run_xdp() may have recycled, redirected, or queued the page for XDP_TX, and an skb free also retires the data buffer. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.8 | 0.55% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53214 | In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix a potential NPD in cleanup_prefix_route() addrconf_get_prefix_route() can return the fib6_null_entry sentinel entry which has a NULL fib6_table pointer. Therefore, before setting the route's expiration time, check that we are not working with this entry, as otherwise a NPD will be triggered [1]. Note that the other callers of addrconf_get_prefix_route() are not susceptible to this bug: 1. addrconf_prefix_rcv(): Req | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.12% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53213 | In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53212 | In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets that took a reference via dst_hold() in nft_tunnel_obj_eval() and are still queued (e.g. in a netem qdisc) are left with a dangling pointer. When these packets are eventually dequeued, dst_release() operates on freed memory. Replace me | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.12% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53211 | In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register NFT_META_BRI_IIFHWADDR declares its destination register with len = ETH_ALEN (6 bytes), which the register-init tracking rounds up to two 32-bit registers (8 bytes). nft_meta_bridge_get_eval() then does memcpy(dest, br_dev->dev_addr, ETH_ALEN), writing only 6 bytes and leaving the upper 2 bytes of the second register as uninitialised nft_do_chain() stack. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53210 | In the Linux kernel, the following vulnerability has been resolved: tee: shm: fix shm leak in register_shm_helper() register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53209 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Existing advertising instances can already hold the maximum extended advertising payload. When hci_adv_bcast_annoucement() prepends the Broadcast Announcement service data to that payload, the combined data may no longer fit in the temporary buffer used to rebuild the advertising data. Reject that case before copying the existing payload and report the failu | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53208 | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.12% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53207 | In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock when racing with a concurrent unmap: thread#0 thread#1 -------- -------- madvise(folio, MADV_HWPOISON) -> poisons the folio successfully | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.10% | 2026-06-25 | 2026-07-02 |