CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2026-23038 – pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()
https://notcve.org/view.php?id=CVE-2026-23038
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node() In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak. Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources. In the Linux kernel, the following vulnerability has... • https://git.kernel.org/stable/c/d67ae825a59d639e4d8b82413af84d854617a87e •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2026-23033 – dmaengine: omap-dma: fix dma_pool resource leak in error paths
https://notcve.org/view.php?id=CVE-2026-23033
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool resource leak in error paths The dma_pool created by dma_pool_create() is not destroyed when dma_async_device_register() or of_dma_controller_register() fails, causing a resource leak in the probe error paths. Add dma_pool_destroy() in both error paths to properly release the allocated dma_pool resource. In the Linux kernel, the following vulnerability has been resolved: dmaengine: omap-dma: fix dma_pool re... • https://git.kernel.org/stable/c/7bedaa5537604f34d1d63c5ec7891e559d2a61ed •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2026-23031 – can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak
https://notcve.org/view.php?id=CVE-2026-23031
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak In gs_can_open(), the URBs for USB-in transfers are allocated, added to the parent->rx_submitted anchor and submitted. In the complete callback gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In gs_can_close() the URBs are freed by calling usb_kill_anchored_urbs(parent->rx_submitted). However, this does not take into account that the USB framework unancho... • https://git.kernel.org/stable/c/d08e973a77d128b25e01a08c34d89593fdf222da •
CVSS: 5.6EPSS: 0%CPEs: 4EXPL: 0CVE-2025-71191 – dmaengine: at_hdmac: fix device leak on of_dma_xlate()
https://notcve.org/view.php?id=CVE-2025-71191
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_hdmac: fix device leak on of_dma_xlate() Make sure to drop the reference taken when looking up the DMA platform device during of_dma_xlate() when releasing channel resources. Note that commit 3832b78b3ec2 ("dmaengine: at_hdmac: add missing put_device() call in at_dma_xlate()") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation. In the Linux kernel, the following vulnerability ... • https://git.kernel.org/stable/c/bbe89c8e3d598129b728d1388c3ad9abe4e8e261 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2025-71188 – dmaengine: lpc18xx-dmamux: fix device leak on route allocation
https://notcve.org/view.php?id=CVE-2025-71188
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. In the Linux kernel, the following vulnerability has been resolved: dmaengine: lpc18xx-dmamux: fix device leak on route allocation Make ... • https://git.kernel.org/stable/c/e5f4ae84be7421010780984bdc121eac15997327 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2025-71185 – dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation
https://notcve.org/view.php?id=CVE-2025-71185
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation. In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation. • https://git.kernel.org/stable/c/42dbdcc6bf965997c088caff2a8be7f9bf44f701 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2026-23021 – net: usb: pegasus: fix memory leak in update_eth_regs_async()
https://notcve.org/view.php?id=CVE-2026-23021
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: fix memory leak in update_eth_regs_async() When asynchronously writing to the device registers and if usb_submit_urb() fail, the code fail to release allocated to this point resources. In the Linux kernel, the following vulnerability has been resolved: net: usb: pegasus: fix memory leak in update_eth_regs_async() When asynchronously writing to the device registers and if usb_submit_urb() fail, the code fail to release all... • https://git.kernel.org/stable/c/323b34963d113efb566635f43858f40cce01d5f9 •
CVSS: 7.2EPSS: 0%CPEs: 3EXPL: 0CVE-2025-71184 – btrfs: fix NULL dereference on root when tracing inode eviction
https://notcve.org/view.php?id=CVE-2025-71184
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix NULL dereference on root when tracing inode eviction When evicting an inode the first thing we do is to setup tracing for it, which implies fetching the root's id. But in btrfs_evict_inode() the root might be NULL, as implied in the next check that we do in btrfs_evict_inode(). Hence, we either should set the ->root_objectid to 0 in case the root is NULL, or we move tracing setup after checking that the root is not NULL. Setting ... • https://git.kernel.org/stable/c/1abe9b8a138c9988ba8f7bfded6453649a31541f •
CVSS: 6.3EPSS: 0%CPEs: 9EXPL: 0CVE-2025-71183 – btrfs: always detect conflicting inodes when logging inode refs
https://notcve.org/view.php?id=CVE-2025-71183
31 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: btrfs: always detect conflicting inodes when logging inode refs After rename exchanging (either with the rename exchange operation or regular renames in multiple non-atomic steps) two inodes and at least one of them is a directory, we can end up with a log tree that contains only of the inodes and after a power failure that can result in an attempt to delete the other inode when it should not because it was not deleted before the power fail... • https://git.kernel.org/stable/c/56f23fdbb600e6087db7b009775b95ce07cc3195 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2026-23011 – ipv4: ip_gre: make ipgre_header() robust
https://notcve.org/view.php?id=CVE-2026-23011
25 Jan 2026 — In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_gre: make ipgre_header() robust Analog to commit db5b4e39c4e6 ("ip6_gre: make ip6gre_header() robust") Over the years, syzbot found many ways to crash the kernel in ipgre_header() [1]. This involves team or bonding drivers ability to dynamically change their dev->needed_headroom and/or dev->hard_header_len In this particular crash mld_newpack() allocated an skb with a too small reserve/headroom, and by the time mld_sendpack() was c... • https://git.kernel.org/stable/c/c54419321455631079c7d6e60bc732dd0c5914c5 •