CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2026-23361 – PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry
https://notcve.org/view.php?id=CVE-2026-23361
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry Endpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X interrupt to the host using a writel(), which generates a PCI posted write transaction. There's no completion for posted writes, so the writel() may return before the PCI write completes. dw_pcie_ep_raise_msix_irq() also unmaps the outbound ATU entry used for the PCI write, so the write races with the unmap. If t... • https://git.kernel.org/stable/c/beb4641a787df79a1423a8789d185b6b78fcbfea •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2026-23360 – nvme: fix admin queue leak on controller reset
https://notcve.org/view.php?id=CVE-2026-23360
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: nvme: fix admin queue leak on controller reset When nvme_alloc_admin_tag_set() is called during a controller reset, a previous admin queue may still exist. Release it properly before allocating a new one to avoid orphaning the old queue. This fixes a regression introduced by commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime"). • https://git.kernel.org/stable/c/a505f0ba36ab24176c300d7ff56aff85c2977e6c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2026-23359 – bpf: Fix stack-out-of-bounds write in devmap
https://notcve.org/view.php?id=CVE-2026-23359
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack-out-of-bounds write in devmap get_upper_ifindexes() iterates over all upper devices and writes their indices into an array without checking bounds. Also the callers assume that the max number of upper devices is MAX_NEST_DEV and allocate excluded_devices[1+MAX_NEST_DEV] on the stack, but that assumption is not correct and the number of upper devices could be larger than MAX_NEST_DEV (e.g., many macvlans), causing a stack-out-... • https://git.kernel.org/stable/c/aeea1b86f9363f3feabb496534d886f082a89f21 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2026-23357 – can: mcp251x: fix deadlock in error path of mcp251x_open
https://notcve.org/view.php?id=CVE-2026-23357
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but... • https://git.kernel.org/stable/c/bf66f3736a945dd4e92d86427276c6eeab0a6c1d •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2026-23356 – drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock()
https://notcve.org/view.php?id=CVE-2026-23356
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock() Even though we check that we "should" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged "LOGIC BUG for enr=...", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log ext... • https://git.kernel.org/stable/c/08a1ddab6df7d3c7b6341774cb1cf4b21b96a214 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2026-23352 – x86/efi: defer freeing of boot services memory
https://notcve.org/view.php?id=CVE-2026-23352
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: x86/efi: defer freeing of boot services memory efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA using memblock_free_late(). There are two issue with that: memblock_free_late() should be used for memory allocated with memblock_alloc() while the memory reserved with memblock_reserve() should be freed with free_reserved_area(). More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y efi_free_boo... • https://git.kernel.org/stable/c/0aed459e8487eb6ebdb4efe8cefe1eafbc704b30 •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2026-23351 – netfilter: nft_set_pipapo: split gc into unlink and reclaim phase
https://notcve.org/view.php?id=CVE-2026-23351
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: split gc into unlink and reclaim phase Yiming Qian reports Use-after-free in the pipapo set type: Under a large number of expired elements, commit-time GC can run for a very long time in a non-preemptible context, triggering soft lockup warnings and RCU stall reports (local denial of service). We must split GC in an unlink and a reclaim phase. We cannot queue elements for freeing until pointers have been swapped. ... • https://git.kernel.org/stable/c/3c4287f62044a90e73a561aa05fc46e62da173da •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2026-23348 – cxl: Fix race of nvdimm_bus object when creating nvdimm objects
https://notcve.org/view.php?id=CVE-2026-23348
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: cxl: Fix race of nvdimm_bus object when creating nvdimm objects Found issue during running of cxl-translate.sh unit test. Adding a 3s sleep right before the test seems to make the issue reproduce fairly consistently. The cxl_translate module has dependency on cxl_acpi and causes orphaned nvdimm objects to reprobe after cxl_acpi is removed. The nvdimm_bus object is registered by the cxl_nvb object when cxl_acpi_probe() is called. With the nv... • https://git.kernel.org/stable/c/8fdcb1704f61a8fd9be0f3849a174d084def0666 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2026-23347 – can: usb: f81604: correctly anchor the urb in the read bulk callback
https://notcve.org/view.php?id=CVE-2026-23347
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: can: usb: f81604: correctly anchor the urb in the read bulk callback When submitting an urb, that is using the anchor pattern, it needs to be anchored before submitting it otherwise it could be leaked if usb_kill_anchored_urbs() is called. This logic is correctly done elsewhere in the driver, except in the read bulk callback so do that here also. • https://git.kernel.org/stable/c/88da17436973e463bed59bea79771fb03a21555e •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2026-23346 – arm64: io: Extract user memory type in ioremap_prot()
https://notcve.org/view.php?id=CVE-2026-23346
25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from iorem... • https://git.kernel.org/stable/c/893dea9ccd08dab924839354aba21d4ed7a9abc0 •