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-53243 | In the Linux kernel, the following vulnerability has been resolved: rseq: Fix using an uninitialized stack variable in rseq_exit_user_update() There is an bug in which an uninitialized stack variable is used in rseq_exit_user_update() as reported by syzbot: BUG: KMSAN: kernel-infoleak in rseq_set_ids_get_csaddr include/linux/rseq_entry.h:502 [inline] The local variable: struct rseq_ids ids = { .cpu_id = task_cpu(t), .mm_cid = task_mm_cid(t), .node_id = cpu_to_node(ids.cpu_id), }; | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.11% | 2026-06-25 | 2026-07-07 |
| CVE-2026-53242 | In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-07-07 |
| CVE-2026-53241 | In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: dummy: fix UMP event stack overread The dummy sequencer port forwards events by copying an incoming struct snd_seq_event into a stack temporary, rewriting source and destination, and dispatching the temporary to subscribers. That legacy event storage is smaller than struct snd_seq_ump_event. When a UMP event reaches the dummy client, the copy leaves the UMP flag set but only provides legacy-sized stack storage. The | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-07 |
| CVE-2026-53240 | In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload __input_process_payload() stores first_skb into xtfs->ra_newskb under drop_lock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ra_newskb without the lock to decide whether first_skb is still owned: if (first_skb && first_iplen && !defer && first_skb != xtfs->ra_newskb) Between spi | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.42% | 2026-06-25 | 2026-07-08 |
| CVE-2026-53239 | In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-07-08 |
| CVE-2026-53238 | In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-08 |
| CVE-2026-53237 | In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereferenc | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-08 |
| CVE-2026-53236 | In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.13% | 2026-06-25 | 2026-07-08 |
| CVE-2026-53235 | In the Linux kernel, the following vulnerability has been resolved: net: add pskb_may_pull() to skb_gro_receive_list() skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without first ensuring the data is in the linear area via pskb_may_pull(). When the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in page fragments) while skb_gro_offset is non-zero (after IP+TCP header parsing). The skb_pull() then decrements skb->len by skb_gro_offset but skb->data_len stays u | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.47% | 2026-06-25 | 2026-07-08 |
| CVE-2026-53234 | In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: Fix use-after-free during device removal The driver was using devm_register_netdev() which causes unregister_netdev() to be deferred until the devres cleanup phase, which runs after emac_remove() returns. This creates a use-after-free window where: 1. emac_remove() is called, which tears down hardware (cancels work, detaches modules, unregisters from MAL) 2. emac_remove() returns 3. devres cleanup runs and | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.13% | 2026-06-25 | 2026-07-08 |
| CVE-2026-53233 | In the Linux kernel, the following vulnerability has been resolved: netdev: fix double-free in netdev_nl_bind_rx_doit() Sashiko flags that genlmsg_reply() always consumes the skb. The error path calls nlmsg_free(rsp) so we can't jump directly to it. Let's not unbind, just propagate the error to the user. This is the typical way of handling genlmsg_reply() failures. They shouldn't happen unless user does something silly like calling the kernel with an already-full rcvbuf. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.8 | 0.14% | 2026-06-25 | 2026-07-07 |
| CVE-2026-53232 | In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves. | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.8 | 0.16% | 2026-06-25 | 2026-07-07 |
| CVE-2026-53231 | In the Linux kernel, the following vulnerability has been resolved: net: phy: don't try to setup PHY-driven SFP cages when using genphy We don't have support for PHY-driver SFP cages with the genphy code. On top of that, it was found by sashiko that running sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers. This problem was reproduced, and does lead to a deadlock on RTNL. Before the blamed commit, the phy_ | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.09% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53230 | In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ff | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 8.7 | 0.13% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53229 | In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the lea | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 7.5 | 0.47% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53228 | In the Linux kernel, the following vulnerability has been resolved: ipv6: sit: reload inner IPv6 header after GSO offloads ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function entry and continues using it after iptunnel_handle_offloads(). For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone(). When the skb header is cloned, skb_header_unclone() can call pskb_expand_head(), which may move the skb head. The pskb_expand_head() contract requires pointers into the skb | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 9.8 | 0.56% | 2026-06-25 | 2026-07-02 |
| CVE-2026-53227 | In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and ex | 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | 5.5 | 0.14% | 2026-06-25 | 2026-07-02 |
| 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 |