Page 5 of 12643 results (0.010 seconds)

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free. • https://git.kernel.org/stable/c/88095e7b473a3d9ec3b9c60429576e9cbd327c89 • CWE-476: NULL Pointer Dereference •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix use-after-free on disconnect The vub300 driver maintains an explicit reference count for the controller and its driver data and the last reference can in theory be dropped after the driver has been unbound. This specifically means that the controller allocation must not be device managed as that can lead to use-after-free. Note that the lifetime is currently also incorrectly tied the parent USB device rather than interface,... • https://git.kernel.org/stable/c/dcfdd698dc521c6046e9b80c16281575efb25d23 • CWE-416: Use After Free •

CVSS: 9.8EPSS: 0%CPEs: 8EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a ... • https://git.kernel.org/stable/c/286a837217204b1ef105e3a554d0757e4fdfaac1 • CWE-190: Integer Overflow or Wraparound •

CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: mm: filemap: fix nr_pages calculation overflow in filemap_map_pages() When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I encountered some very strange crash issues showing up as "Bad page state": " [ 734.496287] BUG: Bad page state in process stress-ng-env pfn:415735fb [ 734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb [ 734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|... • https://git.kernel.org/stable/c/fe601b70eac6cd266e8d7d55030e90a73ed0e339 • CWE-190: Integer Overflow or Wraparound •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling Switch from using the completion's raw spinlock to a local lock in the idpf_vc_xn struct. The conversion is safe because complete/_all() are called outside the lock and there is no reason to share the completion lock in the current logic. This avoids invalid wait context reported by the kernel due to the async handler taking BH spinlock: [ 805.726977] =======================... • https://git.kernel.org/stable/c/34c21fa894a1af6166f4284c81d1dc21efed8f38 •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool() page_pool_create() can return an ERR_PTR on failure. The return value is used unconditionally in the loop that follows, passing the error pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(), which dereferences it, causing a kernel oops. Add an IS_ERR check after page_pool_create() to return early on failure. • https://git.kernel.org/stable/c/11871aba19748b3387e83a2db6360aa7119e9a1a • CWE-476: NULL Pointer Dereference •

CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page pool leak in error paths lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if the subsequent fdma_alloc_coherent() call fails, leaking the pool. Similarly, lan966x_fdma_init() frees the coherent DMA memory when lan966x_fdma_tx_alloc() fails but does not destroy the page pool that was successfully created by lan966x_fdma_rx_alloc(), leaking it. Add the missing page_pool_destroy() calls in both error p... • https://git.kernel.org/stable/c/11871aba19748b3387e83a2db6360aa7119e9a1a • CWE-401: Missing Release of Memory after Effective Lifetime •

CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix use-after-free and leak in lan966x_fdma_reload() When lan966x_fdma_reload() fails to allocate new RX buffers, the restore path restarts DMA using old descriptors whose pages were already freed via lan966x_fdma_rx_free_pages(). Since page_pool_put_full_page() can release pages back to the buddy allocator, the hardware may DMA into memory now owned by other kernel subsystems. Additionally, on the restore path, the newly crea... • https://git.kernel.org/stable/c/89ba464fcf548d64bc7215dfe769f791330ae8b6 • CWE-416: Use After Free •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix key parsing memleak In rxrpc_preparse_xdr_yfs_rxgk(), the memory attached to token->rxgk can be leaked in a few error paths after it's allocated. Fix this by freeing it in the "reject_token:" case. • https://git.kernel.org/stable/c/0ca100ff4df64f5d0f6c1dd5080c3e096786bea6 • CWE-401: Missing Release of Memory after Effective Lifetime •

CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0

24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_call... • https://git.kernel.org/stable/c/2baec2c3f854d1f79c7bb28386484e144e864a14 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •