CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2026-31645 – net: lan966x: fix page pool leak in error paths
https://notcve.org/view.php?id=CVE-2026-31645
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: 0CVE-2026-31644 – net: lan966x: fix use-after-free and leak in lan966x_fdma_reload()
https://notcve.org/view.php?id=CVE-2026-31644
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: 5EXPL: 0CVE-2026-31642 – rxrpc: Fix call removal to use RCU safe deletion
https://notcve.org/view.php?id=CVE-2026-31642
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') •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2026-31639 – rxrpc: Fix key reference count leak from call->key
https://notcve.org/view.php?id=CVE-2026-31639
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix key reference count leak from call->key When creating a client call in rxrpc_alloc_client_call(), the code obtains a reference to the key. This is never cleaned up and gets leaked when the call is destroyed. Fix this by freeing call->key in rxrpc_destroy_call(). Before the patch, it shows the key reference counter elevated: $ cat /proc/keys | grep afs@54321 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka $ A... • https://git.kernel.org/stable/c/f3441d4125fc98995858550a5521b8d7daf0504a •
CVSS: 7.5EPSS: 0%CPEs: 5EXPL: 0CVE-2026-31638 – rxrpc: Only put the call ref if one was acquired
https://notcve.org/view.php?id=CVE-2026-31638
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: Only put the call ref if one was acquired rxrpc_input_packet_on_conn() can process a to-client packet after the current client call on the channel has already been torn down. In that case chan->call is NULL, rxrpc_try_get_call() returns NULL and there is no reference to drop. The client-side implicit-end error path does not account for that and unconditionally calls rxrpc_put_call(). This turns a protocol error path into a kernel cra... • https://git.kernel.org/stable/c/5e6ef4f1017c7f844e305283bbd8875af475e2fc • CWE-476: NULL Pointer Dereference •
CVSS: 9.8EPSS: 0%CPEs: 5EXPL: 0CVE-2026-31637 – rxrpc: reject undecryptable rxkad response tickets
https://notcve.org/view.php?id=CVE-2026-31637
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKAD... • https://git.kernel.org/stable/c/17926a79320afa9b95df6b977b40cca6d8713cea •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2026-31634 – rxrpc: fix reference count leak in rxrpc_server_keyring()
https://notcve.org/view.php?id=CVE-2026-31634
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set. • https://git.kernel.org/stable/c/17926a79320afa9b95df6b977b40cca6d8713cea •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2026-31630 – rxrpc: proc: size address buffers for %pISpc output
https://notcve.org/view.php?id=CVE-2026-31630
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case suc... • https://git.kernel.org/stable/c/75b54cb57ca34cbe7a87c6ac757c55360a624590 •
CVSS: 8.8EPSS: 0%CPEs: 6EXPL: 0CVE-2026-31629 – nfc: llcp: add missing return after LLCP_CLOSED checks
https://notcve.org/view.php?id=CVE-2026-31629
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), lea... • https://git.kernel.org/stable/c/d646960f7986fefb460a2b062d5ccc8ccfeacc3a • CWE-667: Improper Locking •
CVSS: 5.5EPSS: 0%CPEs: 12EXPL: 0CVE-2026-31628 – x86/CPU: Fix FPDSS on Zen1
https://notcve.org/view.php?id=CVE-2026-31628
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit. • https://git.kernel.org/stable/c/f7f3dc00f61261cdc9ccd8b886f21bc4dffd6fd9 •