CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2026-43016 – bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready().
https://notcve.org/view.php?id=CVE-2026-43016
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready(). syzbot reported use-after-free of AF_UNIX socket's sk->sk_socket in sk_psock_verdict_data_ready(). [0] In unix_stream_sendmsg(), the peer socket's ->sk_data_ready() is called after dropping its unix_state_lock(). Although the sender socket holds the peer's refcount, it does not prevent the peer's sock_orphan(), and the peer's sk_socket might be freed after o... • https://git.kernel.org/stable/c/c63829182c37c2d6d0608976d15fa61ebebe9e6b • CWE-416: Use After Free •
CVSS: 7.8EPSS: 0%CPEs: 12EXPL: 0CVE-2026-43015 – net: macb: fix clk handling on PCI glue driver removal
https://notcve.org/view.php?id=CVE-2026-43015
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: net: macb: fix clk handling on PCI glue driver removal platform_device_unregister() may still want to use the registered clks during runtime resume callback. Note that there is a commit d82d5303c4c5 ("net: macb: fix use after free on rmmod") that addressed the similar problem of clk vs platform device unregistration but just moved the bug to another place. Save the pointers to clks into local variables for reuse after platform device is unr... • https://git.kernel.org/stable/c/7721221e87d25c9840d9ca6b986dbdc410d5ce2b • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43014 – net: macb: properly unregister fixed rate clocks
https://notcve.org/view.php?id=CVE-2026-43014
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: net: macb: properly unregister fixed rate clocks The additional resources allocated with clk_register_fixed_rate() need to be released with clk_unregister_fixed_rate(), otherwise they are lost. • https://git.kernel.org/stable/c/83a77e9ec4150ee4acc635638f7dedd9da523a26 •
CVSS: 9.8EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43011 – net/x25: Fix potential double free of skb
https://notcve.org/view.php?id=CVE-2026-43011
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls ... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 • CWE-415: Double Free •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2026-43009 – bpf: Fix incorrect pruning due to atomic fetch precision tracking
https://notcve.org/view.php?id=CVE-2026-43009
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: bpf: Fix incorrect pruning due to atomic fetch precision tracking When backtrack_insn encounters a BPF_STX instruction with BPF_ATOMIC and BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts as a destination, thus receiving the old value from the memory location. The current backtracking logic does not account for this. It treats atomic fetch operations the same as regular stores where the src register is only an input. This leads... • https://git.kernel.org/stable/c/5ca419f2864a2c60940dcf4bbaeb69546200e36f •
CVSS: 5.5EPSS: 0%CPEs: 13EXPL: 0CVE-2026-31781 – drm/ioc32: stop speculation on the drm_compat_ioctl path
https://notcve.org/view.php?id=CVE-2026-31781
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: drm/ioc32: stop speculation on the drm_compat_ioctl path The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling array_index_nospec() on the index to the function pointer list. • https://git.kernel.org/stable/c/505b5240329b922f21f91d5b5d1e535c805eca6d •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2026-31780 – wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation
https://notcve.org/view.php?id=CVE-2026-31780
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. Each SSID contributes up to 33 bytes (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10) SSIDs the total can reach 330, which wraps around to 74 when stored in a u8. This causes kmalloc to allocate only 75 bytes while the subsequent memcpy writes up to 331 bytes... • https://git.kernel.org/stable/c/c5c77ba18ea66aa05441c71e38473efb787705a4 • CWE-787: Out-of-bounds Write •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2026-31778 – ALSA: caiaq: fix stack out-of-bounds read in init_card
https://notcve.org/view.php?id=CVE-2026-31778
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_strin... • https://git.kernel.org/stable/c/bafeee5b1f8d32cbf791c322b40a6fa91d8ccf7a • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2026-31777 – ALSA: ctxfi: Check the error for index mapping
https://notcve.org/view.php?id=CVE-2026-31777
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Check the error for index mapping The ctxfi driver blindly assumed a proper value returned from daio_device_index(), but it's not always true. Add a proper error check to deal with the error from the function. • https://git.kernel.org/stable/c/8cc72361481f00253f1e468ade5795427386d593 •
CVSS: 8.8EPSS: 0%CPEs: 9EXPL: 0CVE-2026-31773 – Bluetooth: SMP: derive legacy responder STK authentication from MITM state
https://notcve.org/view.php?id=CVE-2026-31773
01 May 2026 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SMP: derive legacy responder STK authentication from MITM state The legacy responder path in smp_random() currently labels the stored STK as authenticated whenever pending_sec_level is BT_SECURITY_HIGH. That reflects what the local service requested, not what the pairing flow actually achieved. For Just Works/Confirm legacy pairing, SMP_FLAG_MITM_AUTH stays clear and the resulting STK should remain unauthenticated even if the loc... • https://git.kernel.org/stable/c/fff3490f47810e2d34b91fb9e31103e923b11c2f •