Linux Kernel vulnerabilities

CVE-2026-23081 [MEDIUM] CVE-2026-23081: In the Linux kernel, the following vulnerability has been resolved: net: phy: intel-xway: fix OF no In the Linux kernel, the following vulnerability has been resolved: net: phy: intel-xway: fix OF node refcount leakage Automated review spotted am OF node reference count leakage when checking if the 'leds' child node exists. Call of_put_node() to correctly maintain the refcount.

CVE-2026-23096 [MEDIUM] CVE-2026-23096: In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the In the Linux kernel, the following vulnerability has been resolved: uacce: fix cdev handling in the cleanup path When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_devic

CVE-2026-23071 [MEDIUM] CWE-362 CVE-2026-23071: In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in h In the Linux kernel, the following vulnerability has been resolved: regmap: Fix race condition in hwspinlock irqsave routine Previously, the address of the shared member '&map->spinlock_flags' was passed directly to 'hwspin_lock_timeout_irqsave'. This creates a race condition where multiple contexts contending for the lock could overwrite the shar

CVE-2026-23086 [MEDIUM] CVE-2026-23086: In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: cap TX credit to In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: cap TX credit to local buffer size The virtio transports derives its TX credit directly from peer_buf_alloc, which is set from the remote endpoint's SO_VM_SOCKETS_BUFFER_SIZE value. On the host side this means that the amount of data we are willing to queue for a connection

CVE-2026-23082 [MEDIUM] CWE-835 CVE-2026-23082: In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bul In the Linux kernel, the following vulnerability has been resolved: can: gs_usb: gs_usb_receive_bulk_callback(): unanchor URL on usb_submit_urb() error In commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"), the URB was re-anchored before usb_submit_urb() in gs_usb_receive_bulk_callback() to prevent a leak of t

CVE-2026-23101 [MEDIUM] CWE-908 CVE-2026-23101: In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED t In the Linux kernel, the following vulnerability has been resolved: leds: led-class: Only Add LED to leds_list when it is fully ready Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of

CVE-2026-23061 [MEDIUM] CWE-401 CVE-2026-23061: In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_rea In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb: kvaser_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"). In kvaser_usb_set_{,data_}bittiming() -> kvaser_usb_setup_rx_urbs(), the URBs for USB-in t

CVE-2026-23091 [MEDIUM] CWE-401 CVE-2026-23091: In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on ou In the Linux kernel, the following vulnerability has been resolved: intel_th: fix device leak on output open() Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference i

CVE-2026-23072 [MEDIUM] CWE-401 CVE-2026-23072: In the Linux kernel, the following vulnerability has been resolved: l2tp: Fix memleak in l2tp_udp_e In the Linux kernel, the following vulnerability has been resolved: l2tp: Fix memleak in l2tp_udp_encap_recv(). syzbot reported memleak of struct l2tp_session, l2tp_tunnel, sock, etc. [0] The cited commit moved down the validation of the protocol version in l2tp_udp_encap_recv(). The new place requires an extra error handling to avoid the memlea

CVE-2026-23085 [MEDIUM] CVE-2026-23085: In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid trunc In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Avoid truncating memory addresses On 32-bit machines with CONFIG_ARM_LPAE, it is possible for lowmem allocations to be backed by addresses physical memory above the 32-bit address limit, as found while experimenting with larger VMSPLIT configurations. This caused the

CVE-2026-23069 [MEDIUM] CWE-191 CVE-2026-23069: In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential und In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix potential underflow in virtio_transport_get_credit() The credit calculation in virtio_transport_get_credit() uses unsigned arithmetic: ret = vvs->peer_buf_alloc - (vvs->tx_cnt - vvs->peer_fwd_cnt); If the peer shrinks its advertised buffer (peer_buf_alloc) whil

CVE-2026-23107 [MEDIUM] CWE-476 CVE-2026-23107: In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Allocate In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA The code to restore a ZA context doesn't attempt to allocate the task's sve_state before setting TIF_SME. Consequently, restoring a ZA context can place a task into an invalid state where TIF_SME is set but the task's sv

CVE-2026-23087 [MEDIUM] CWE-401 CVE-2026-23087: In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potent In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() Memory allocated for struct vscsiblk_info in scsiback_probe() is not freed in scsiback_remove() leading to potential memory leaks on remove, as well as in the scsiback_probe() error paths. Fix that by freeing it i

CVE-2026-23100 [MEDIUM] CVE-2026-23100: In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_sha In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb_pmd_shared() Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmu_gather)", v3. One functional fix, one performance regression fix, and two related comment fixes. I cleaned up my prototype I recently shared [1] for the performance fix, deferring

CVE-2026-23108 [MEDIUM] CWE-401 CVE-2026-23108: In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bu In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to

CVE-2026-23103 [HIGH] CWE-667 CVE-2026-23103: In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be In the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So 1) Introduce per-port addrs_lock. 2) It was nee

CVE-2026-23065 [MEDIUM] CWE-401 CVE-2026-23065: In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd: Fix memory le In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd: Fix memory leak in wbrf_record() The tmp buffer is allocated using kcalloc() but is not freed if acpi_evaluate_dsm() fails. This causes a memory leak in the error path. Fix this by explicitly freeing the tmp buffer in the error handling path of acpi_evaluate_dsm

CVE-2026-23067 [MEDIUM] CWE-617 CVE-2026-23067: In the Linux kernel, the following vulnerability has been resolved: iommu/io-pgtable-arm: fix size_ In the Linux kernel, the following vulnerability has been resolved: iommu/io-pgtable-arm: fix size_t signedness bug in unmap path __arm_lpae_unmap() returns size_t but was returning -ENOENT (negative error code) when encountering an unmapped PTE. Since size_t is unsigned, -ENOENT (typically -2) becomes a huge positive value (0xFFFFFFFFFFFFFFFE on

CVE-2026-23080 [MEDIUM] CWE-401 CVE-2026-23080: In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bu In the Linux kernel, the following vulnerability has been resolved: can: mcba_usb: mcba_usb_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"). In mcba_usb_probe() -> mcba_usb_start(), the URBs for USB-in transfers are allocated, added to

CVE-2026-23106 [MEDIUM] CVE-2026-23106: In the Linux kernel, the following vulnerability has been resolved: timekeeping: Adjust the leap st In the Linux kernel, the following vulnerability has been resolved: timekeeping: Adjust the leap state for the correct auxiliary timekeeper When __do_ajdtimex() was introduced to handle adjtimex for any timekeeper, this reference to tk_core was not updated. When called on an auxiliary timekeeper, the core timekeeper would be updated incorrectly. This get