CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2026-46333 – ptrace: slightly saner 'get_dumpable()' logic
https://notcve.org/view.php?id=CVE-2026-46333
15 May 2026 — In the Linux kernel, the following vulnerability has been resolved: ptrace: slightly saner 'get_dumpable()' logic The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm. And almost all users do in fact use it only for the case where the task has a mm pointer. But we have one odd special case: ptrace_may_access() uses 'dumpable' to check various other things entirely ind... • https://git.kernel.org/stable/c/93d4ba49d18e3d7fb41a9927c2d0cca5e9dfefd6 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43472 – unshare: fix unshare_fs() handling
https://notcve.org/view.php?id=CVE-2026-43472
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: unshare: fix unshare_fs() handling There's an unpleasant corner case in unshare(2), when we have a CLONE_NEWNS in flags and current->fs hadn't been shared at all; in that case copy_mnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness] > I guess if private means fs->users == 1, the condition could still be true. Unfortunately, it's worse than just a convoluted proof of correctness... • https://git.kernel.org/stable/c/741a295130606143edbf9fc740f633dbc1e6225f •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2026-43456 – bonding: fix type confusion in bond_setup_by_slave()
https://notcve.org/view.php?id=CVE-2026-43456
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: bonding: fix type confusion in bond_setup_by_slave() kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R... • https://git.kernel.org/stable/c/1284cd3a2b740d0118458d2ea470a1e5bc19b187 •
CVSS: 8.2EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43452 – netfilter: x_tables: guard option walkers against 1-byte tail reads
https://notcve.org/view.php?id=CVE-2026-43452
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: guard option walkers against 1-byte tail reads When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area. Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xt_tcpudp and xt_dccp option walkers. • https://git.kernel.org/stable/c/2e4e6a17af35be359cc8f1c924f8f198fbd478cc •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43428 – USB: core: Limit the length of unkillable synchronous timeouts
https://notcve.org/view.php?id=CVE-2026-43428
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: USB: core: Limit the length of unkillable synchronous timeouts The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these u... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43427 – usb: class: cdc-wdm: fix reordering issue in read code path
https://notcve.org/view.php?id=CVE-2026-43427
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: usb: class: cdc-wdm: fix reordering issue in read code path Quoting the bug report: Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdm_read() can see the new length and call copy_to_user() on uninitialized memory. This also violates LKMM data race rules [1]. Fix it by using WRITE_ONCE and memory barriers. • https://git.kernel.org/stable/c/afba937e540c902c989cd516fd97ea0c8499bb27 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43425 – usb: image: mdc800: kill download URB on timeout
https://notcve.org/view.php?id=CVE-2026-43425
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: usb: image: mdc800: kill download URB on timeout mdc800_device_read() submits download_urb and waits for completion. If the timeout fires and the device has not responded, the function returns without killing the URB, leaving it active. A subsequent read() resubmits the same URB while it is still in-flight, triggering the WARN in usb_submit_urb(): "URB submitted while active" Check the return value of wait_event_timeout() and kill the URB i... • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2026-43416 – powerpc, perf: Check that current->mm is alive before getting user callchain
https://notcve.org/view.php?id=CVE-2026-43416
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: powerpc, perf: Check that current->mm is alive before getting user callchain It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to commit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain"). I was getting this panic when running a profiling BPF program (profile.py from bcc-tools): [26215.051935] Kernel attempted to read user page (... • https://git.kernel.org/stable/c/20002ded4d937ca87aca6253b874920a96a763c4 •
CVSS: 9.4EPSS: 0%CPEs: 7EXPL: 0CVE-2026-43383 – net/tcp-md5: Fix MAC comparison to be constant-time
https://notcve.org/view.php?id=CVE-2026-43383
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: net/tcp-md5: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. • https://git.kernel.org/stable/c/cfb6eeb4c860592edd123fdea908d23c6ad1c7dc •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-43363 – x86/apic: Disable x2apic on resume if the kernel expects so
https://notcve.org/view.php?id=CVE-2026-43363
08 May 2026 — In the Linux kernel, the following vulnerability has been resolved: x86/apic: Disable x2apic on resume if the kernel expects so When resuming from s2ram, firmware may re-enable x2apic mode, which may have been disabled by the kernel during boot either because it doesn't support IRQ remapping or for other reasons. This causes the kernel to continue using the xapic interface, while the hardware is in x2apic mode, which causes hangs. This happens on defconfig + bare metal + s2ram. Fix this in lapic_resume() by... • https://git.kernel.org/stable/c/6e1cb38a2aef7680975e71f23de187859ee8b158 •