CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2026-31545 – NFC: nxp-nci: allow GPIOs to sleep
https://notcve.org/view.php?id=CVE-2026-31545
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: NFC: nxp-nci: allow GPIOs to sleep Allow the firmware and enable GPIOs to sleep. This fixes a `WARN_ON' and allows the driver to operate GPIOs which are connected to I2C GPIO expanders. -- >8 -- kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98 -- >8 -- • https://git.kernel.org/stable/c/43201767b44cbd873c60dbd2acd370147588cb18 •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2026-31540 – drm/i915/gt: Check set_default_submission() before deferencing
https://notcve.org/view.php?id=CVE-2026-31540
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Check set_default_submission() before deferencing When the i915 driver firmware binaries are not present, the set_default_submission pointer is not set. This pointer is dereferenced during suspend anyways. Add a check to make sure it is set before dereferencing. [ 23.289926] PM: suspend entry (deep) [ 23.293558] Filesystems sync: 0.000 seconds [ 23.298010] Freezing user space processes [ 23.302771] Freezing user space processes... • https://git.kernel.org/stable/c/ff44ad51ebf8e4693bd66ae41aa37a6bc88a134f • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2026-31537 – smb: server: make use of smbdirect_socket.send_io.bcredits
https://notcve.org/view.php?id=CVE-2026-31537
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: smb: server: make use of smbdirect_socket.send_io.bcredits It turns out that our code will corrupt the stream of reassabled data transfer messages when we trigger an immendiate (empty) send. In order to fix this we'll have a single 'batch' credit per connection. And code getting that credit is free to use as much messages until remaining_length reaches 0, then the batch credit it given back and the next logical send can happen. • https://git.kernel.org/stable/c/0626e6641f6b467447c81dd7678a69c66f7746cf •
CVSS: 9.8EPSS: 0%CPEs: 3EXPL: 0CVE-2026-31536 – smb: server: let send_done handle a completion without IB_SEND_SIGNALED
https://notcve.org/view.php?id=CVE-2026-31536
24 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: smb: server: let send_done handle a completion without IB_SEND_SIGNALED With smbdirect_send_batch processing we likely have requests without IB_SEND_SIGNALED, which will be destroyed in the final request that has IB_SEND_SIGNALED set. If the connection is broken all requests are signaled even without explicit IB_SEND_SIGNALED. • https://git.kernel.org/stable/c/0626e6641f6b467447c81dd7678a69c66f7746cf •
CVSS: 9.8EPSS: 0%CPEs: 8EXPL: 0CVE-2026-31533 – net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption
https://notcve.org/view.php?id=CVE-2026-31533
23 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption The -EBUSY handling in tls_do_encryption(), introduced by commit 859054147318 ("net: tls: handle backlogging of crypto requests"), has a use-after-free due to double cleanup of encrypt_pending and the scatterlist entry. When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to the cryptd backlog and the async callback tls_encrypt_done() will be invoked upon co... • https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368 •
CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0CVE-2026-31532 – can: raw: fix ro->uniq use-after-free in raw_rcv()
https://notcve.org/view.php?id=CVE-2026-31532
23 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). This leaves a window where raw_rcv() may still be running in an RCU read-side critical section after raw_release() frees ro->uniq, leading to a use-after-free of the percpu uniq storage. Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific socket d... • https://git.kernel.org/stable/c/514ac99c64b22d83b52dfee3b8becaa69a92bc4a •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2026-31531 – ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
https://notcve.org/view.php?id=CVE-2026-31531
23 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops. This results in the following warning splat: WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU... • https://git.kernel.org/stable/c/430a049190de3c9e219f43084de9f1122da04570 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2026-31527 – driver core: platform: use generic driver_override infrastructure
https://notcve.org/view.php?id=CVE-2026-31527
22 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: driver core: platform: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock h... • https://git.kernel.org/stable/c/3d713e0e382e6fcfb4bba1501645b66c129ad60b • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2026-31524 – HID: asus: avoid memory leak in asus_report_fixup()
https://notcve.org/view.php?id=CVE-2026-31524
22 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: HID: asus: avoid memory leak in asus_report_fixup() The asus_report_fixup() function was returning a newly allocated kmemdup()-allocated buffer, but never freeing it. Switch to devm_kzalloc() to ensure the memory is managed and freed automatically when the device is removed. The caller of report_fixup() does not take ownership of the returned pointer, but it is permitted to return a pointer whose lifetime is at least that of the input buffe... • https://git.kernel.org/stable/c/5703e52cc711bc01e72cf12b86a126909c79d213 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2026-31523 – nvme-pci: ensure we're polling a polled queue
https://notcve.org/view.php?id=CVE-2026-31523
22 Apr 2026 — In the Linux kernel, the following vulnerability has been resolved: nvme-pci: ensure we're polling a polled queue A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions. • https://git.kernel.org/stable/c/4b04cc6a8f86c4842314def22332de1f15de8523 • CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition •