{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-5.15.0-1109-kvm", "linux-image-5.15.0-1109-kvm", "linux-kvm-headers-5.15.0-1109", "linux-modules-5.15.0-1109-kvm" ], "removed": [ "linux-headers-5.15.0-1108-kvm", "linux-image-5.15.0-1108-kvm", "linux-kvm-headers-5.15.0-1108", "linux-modules-5.15.0-1108-kvm" ], "diff": [ "linux-headers-kvm", "linux-image-kvm", "linux-kvm", "sosreport" ] } }, "diff": { "deb": [ { "name": "linux-headers-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1108.104", "version": "5.15.0.1108.104" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1109.105", "version": "5.15.0.1109.105" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1109", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1109.105", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Thibault Ferrante ", "date": "Thu, 10 Sep 2026 16:08:07 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1108.104", "version": "5.15.0.1108.104" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1109.105", "version": "5.15.0.1109.105" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1109", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1109.105", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Thibault Ferrante ", "date": "Thu, 10 Sep 2026 16:08:07 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm", "from_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1108.104", "version": "5.15.0.1108.104" }, "to_version": { "source_package_name": "linux-meta-kvm", "source_package_version": "5.15.0.1109.105", "version": "5.15.0.1109.105" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Bump ABI 5.15.0-1109", "" ], "package": "linux-meta-kvm", "version": "5.15.0.1109.105", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [], "author": "Thibault Ferrante ", "date": "Thu, 10 Sep 2026 16:08:07 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "sosreport", "from_version": { "source_package_name": "sosreport", "source_package_version": "4.10.2-0ubuntu0~22.04.1", "version": "4.10.2-0ubuntu0~22.04.1" }, "to_version": { "source_package_name": "sosreport", "source_package_version": "4.11.2-0ubuntu0~22.04.1", "version": "4.11.2-0ubuntu0~22.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2156921 ], "changes": [ { "cves": [], "log": [ "", " * New 4.11.2 upstream release. (LP: #2156921)", "", " * For more details, full release note is available here:", " - https://github.com/sosreport/sos/releases/tag/4.11.2", "", " * d/control:", " - Update Vcs-Browser and Vcs-Git to reflect the Salsa repository migration", " to Debian Python Team", " - Add xz-utils to Depends", "", " *d/copyright: Aligned copyright with Debian", "" ], "package": "sosreport", "version": "4.11.2-0ubuntu0~22.04.1", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2156921 ], "author": "Dan Emmons ", "date": "Fri, 26 Jun 2026 23:02:00 +0000" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-5.15.0-1109-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": "5.15.0-1109.114" }, "cves": [ { "cve": "CVE-2026-64582", "url": "https://ubuntu.com/security/CVE-2026-64582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix a use-after-free problem in rxe_mmap rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1: list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */ ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */ [...] rxe_vma_open(vma); /* kref_get, ref → 2 */ remap_vmalloc_range_partial() walks PTEs without any lock. A concurrent DESTROY_CQ ioctl on another CPU calls: kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */ vfree(ip->obj) /* clears vmalloc PTEs mid-walk */ kfree(ip) /* frees rxe_mmap_info */ This yields: 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF. It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get). The call trace are as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:validate_page_before_insert+0x32/0x300 Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5 RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00 R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20 FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0 Call Trace: insert_page+0x8f/0x190 ? __pfx_insert_page+0x10/0x10 ? kasan_save_alloc_info+0x38/0x60 vm_insert_page+0x2e7/0x400 remap_vmalloc_range_partial+0x212/0x3e0 remap_vmalloc_range+0x6e/0xb0 ? __kasan_check_write+0x14/0x30 rxe_mmap+0x2e9/0x5d0 ib_uverbs_mmap+0x1ad/0x2c0 __mmap_region+0x12c2/0x2ad0 ? __pfx___mmap_region+0x10/0x10 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_prev_slot+0x360/0x39c0 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_next_slot+0x1e5b/0x2f40 ? __sanitizer_cov_trace_cmp8+0x18/0x30 ? unmapped_area_topdown+0x4dd/0x610 ? kfree+0x1b1/0x440 ? free_cpumask_var+0x16/0x30 ? __kasan_slab_free+0x7d/0xa0 ? __sanitizer_cov_trace_cmp8+0x18/0x30 mmap_region+0x2e6/0x3c0 do_mmap+0xa3e/0x12a0 ? __pfx_do_mmap+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? down_write_killable+0xba/0x160 ? __pfx_down_write_killable+0x10/0x10 ? __sanitizer_cov_trace_cmp4+0x16/0x30 vm_mmap_pgoff+0x2d4/0x4a0 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x1bf/0x270 ksys_mmap_pgoff+0x40c/0x690 ? __sanitizer_cov_trace_const_cmp4+0x16/0x30 ? __pfx_ksys_mmap_pgoff+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? _raw_spin_trylock+0xbb/0x130 ? __pfx__raw_spin_trylock+0x10/0x10 __x64_sys_mmap+0x135/0x1e0 x64_sys_c ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-05 12:18:00 UTC" }, { "cve": "CVE-2026-74468", "url": "https://ubuntu.com/security/CVE-2026-74468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 (\"gpio: sch: use raw_spinlock_t in the irq startup path\") and commit 90f0109019e6 (\"gpio: eic-sprd: use raw_spinlock_t in the irq startup path\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74482", "url": "https://ubuntu.com/security/CVE-2026-74482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74443", "url": "https://ubuntu.com/security/CVE-2026-74443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at \t(unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74444", "url": "https://ubuntu.com/security/CVE-2026-74444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes \tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74453", "url": "https://ubuntu.com/security/CVE-2026-74453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the \"Auto-initialise Tile State Data Array\" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74455", "url": "https://ubuntu.com/security/CVE-2026-74455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: validate uCAN receive record lengths pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74456", "url": "https://ubuntu.com/security/CVE-2026-74456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 (\"net: usb: lan78xx: Fix double free issue with interrupt buffer allocation\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74457", "url": "https://ubuntu.com/security/CVE-2026-74457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74458", "url": "https://ubuntu.com/security/CVE-2026-74458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74459", "url": "https://ubuntu.com/security/CVE-2026-74459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74460", "url": "https://ubuntu.com/security/CVE-2026-74460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74461", "url": "https://ubuntu.com/security/CVE-2026-74461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74463", "url": "https://ubuntu.com/security/CVE-2026-74463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74464", "url": "https://ubuntu.com/security/CVE-2026-74464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74465", "url": "https://ubuntu.com/security/CVE-2026-74465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the \"hash\" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68451", "url": "https://ubuntu.com/security/CVE-2026-68451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA ECC private key requests cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "high", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68452", "url": "https://ubuntu.com/security/CVE-2026-68452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-74467", "url": "https://ubuntu.com/security/CVE-2026-74467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Check CAP_NET_ADMIN for private ioctls Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74469", "url": "https://ubuntu.com/security/CVE-2026-74469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74471", "url": "https://ubuntu.com/security/CVE-2026-74471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Check return value of __register_event() in trace_module_add_events() trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74473", "url": "https://ubuntu.com/security/CVE-2026-74473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74475", "url": "https://ubuntu.com/security/CVE-2026-74475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74478", "url": "https://ubuntu.com/security/CVE-2026-74478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: vector: fix use-after-free in vector_mmsg_rx() When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: \tif (header_check < 0) { \t\tdev_kfree_skb_irq(skb); \t\tvp->estats.rx_encaps_errors++; \t\tcontinue; \t} The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: \t(*skbuff_vector) = NULL; \tmmsg_vector++; \tskbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74480", "url": "https://ubuntu.com/security/CVE-2026-74480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74481", "url": "https://ubuntu.com/security/CVE-2026-74481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74485", "url": "https://ubuntu.com/security/CVE-2026-74485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: reject a flag character as the field delimiter The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: \tmemset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering \tPaPEPPxPPiP with 'P' as the delimiter (name \"a\", type extension, magic \"x\", interpreter \"i\", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74488", "url": "https://ubuntu.com/security/CVE-2026-74488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: \trx_skb = __skb_dequeue(&list); \trx_hdr = (struct rx_packet_hdr *)rx_skb->data; \tif (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && \t ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { \t\tmwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, \t\t\t\t\t\t skb->len); \t} The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with \tif (!reuse_skb) \t\tdev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes \ties_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, \tfor (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { \t\tu8 ie_len = pos[1]; \t\tif (pos + 2 + ie_len > end) \t\t\tbreak; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74490", "url": "https://ubuntu.com/security/CVE-2026-74490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74492", "url": "https://ubuntu.com/security/CVE-2026-74492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: do not update comments from kernel-side hash adds mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74493", "url": "https://ubuntu.com/security/CVE-2026-74493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket use-after-free during link group termination __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74495", "url": "https://ubuntu.com/security/CVE-2026-74495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74497", "url": "https://ubuntu.com/security/CVE-2026-74497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74498", "url": "https://ubuntu.com/security/CVE-2026-74498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74499", "url": "https://ubuntu.com/security/CVE-2026-74499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() snd_usbmidi_akai_output() computes its fill-loop bound \tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74505", "url": "https://ubuntu.com/security/CVE-2026-74505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74507", "url": "https://ubuntu.com/security/CVE-2026-74507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74508", "url": "https://ubuntu.com/security/CVE-2026-74508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74512", "url": "https://ubuntu.com/security/CVE-2026-74512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74518", "url": "https://ubuntu.com/security/CVE-2026-74518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocate_file_region_entries() allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74519", "url": "https://ubuntu.com/security/CVE-2026-74519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-74523", "url": "https://ubuntu.com/security/CVE-2026-74523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74525", "url": "https://ubuntu.com/security/CVE-2026-74525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: free TX rings on RX allocation failure When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74540", "url": "https://ubuntu.com/security/CVE-2026-74540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74546", "url": "https://ubuntu.com/security/CVE-2026-74546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74547", "url": "https://ubuntu.com/security/CVE-2026-74547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74548", "url": "https://ubuntu.com/security/CVE-2026-74548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix UAF of txrx_stats in nv_remove nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74549", "url": "https://ubuntu.com/security/CVE-2026-74549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74556", "url": "https://ubuntu.com/security/CVE-2026-74556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74557", "url": "https://ubuntu.com/security/CVE-2026-74557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: \tsenselen = get_unaligned_be16(data); \tif (datalen < senselen) \t\tgoto invalid_datalen; \tmemcpy(sc->sense_buffer, data + 2, \t min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74563", "url": "https://ubuntu.com/security/CVE-2026-74563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74579", "url": "https://ubuntu.com/security/CVE-2026-74579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes.", "cve_priority": "medium", "cve_public_date": "2026-08-17 06:19:00 UTC" }, { "cve": "CVE-2026-74564", "url": "https://ubuntu.com/security/CVE-2026-74564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74566", "url": "https://ubuntu.com/security/CVE-2026-74566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: make keyring key-chunk byte order agree with keyring_diff_objects() keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74567", "url": "https://ubuntu.com/security/CVE-2026-74567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74569", "url": "https://ubuntu.com/security/CVE-2026-74569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and \"datalen = datalen + diff - msglen\" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-43491", "url": "https://ubuntu.com/security/CVE-2026-43491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-74577", "url": "https://ubuntu.com/security/CVE-2026-74577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: \tr = nlmsg_data(nlh); \tr->rtm_family\t = AF_MPLS; \tr->rtm_dst_len\t= 20; \tr->rtm_src_len\t= 0; \tr->rtm_table\t= RT_TABLE_MAIN; \tr->rtm_type\t= RTN_UNICAST; \tr->rtm_scope\t= RT_SCOPE_UNIVERSE; \tr->rtm_protocol = rt->rt_protocol; \tr->rtm_flags\t= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64543", "url": "https://ubuntu.com/security/CVE-2026-64543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix use-after-free of the discoverer in tipc_disc_rcv() bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(), but tipc_disc_rcv() still dereferences b->disc in RX softirq under rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv). L2 bearers are safe thanks to the synchronize_net() in tipc_disable_l2_media(), but the UDP bearer defers that call to the cleanup_bearer() workqueue, so the discoverer is freed with no grace period: BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149) Read of size 8 at addr ffff88802348b728 by task poc_tipc/184 tipc_disc_rcv (net/tipc/discover.c:149) tipc_rcv (net/tipc/node.c:2126) tipc_udp_recv (net/tipc/udp_media.c:391) udp_rcv (net/ipv4/udp.c:2643) ip_local_deliver_finish (net/ipv4/ip_input.c:241) Freed by task 181: kfree (mm/slub.c:6565) bearer_disable (net/tipc/bearer.c:418) tipc_nl_bearer_disable (net/tipc/bearer.c:1001) The bearer is freed with kfree_rcu(); free the discoverer the same way. Add an rcu_head to struct tipc_discoverer and free it and its skb from an RCU callback. Because the RCU callback (tipc_disc_free_rcu) lives in module text, a call_rcu() that is still pending when the tipc module is unloaded would invoke a freed function. Add an rcu_barrier() to tipc_exit() after the bearer subsystem has been torn down, so all pending discoverer callbacks have run before the module text goes away. Reachable from an unprivileged user namespace: the TIPCv2 genl family is netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC and CONFIG_TIPC_MEDIA_UDP.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72123", "url": "https://ubuntu.com/security/CVE-2026-72123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 (\"can: bcm: use call_rcu() instead of costly synchronize_rcu()\") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a \"scheduling while atomic\" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72019", "url": "https://ubuntu.com/security/CVE-2026-72019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d (\"macvlan: do not assume mac_header is set in macvlan_broadcast()\") for exactly this purpose.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-52977", "url": "https://ubuntu.com/security/CVE-2026-52977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-72282", "url": "https://ubuntu.com/security/CVE-2026-72282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72068", "url": "https://ubuntu.com/security/CVE-2026-72068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64301", "url": "https://ubuntu.com/security/CVE-2026-64301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error path where process_scmi_regulator_of_node() fails, the function returns without calling of_node_put() on the child node, leaking the reference. Add of_node_put(np) on the error path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64304", "url": "https://ubuntu.com/security/CVE-2026-64304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - validate RSA CRT component lengths The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64593", "url": "https://ubuntu.com/security/CVE-2026-64593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not trim a device which is not writeable [BUG] There is a bug report that btrfs/242 can randomly fail with the following NULL pointer dereference: run fstests btrfs/242 at 2026-06-01 10:25:08 BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609) BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874 BTRFS info (device sdc): using crc32c checksum algorithm BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS info (device sdc): allowing degraded mounts BTRFS info (device sdc): turning on async discard BTRFS info (device sdc): enabling free space tree Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000 CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_trim_fs+0x34c/0xa00 [btrfs] lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs] Call trace: btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P) btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] __arm64_sys_ioctl+0xac/0x108 invoke_syscall.constprop.0+0x5c/0xd0 el0_svc_common.constprop.0+0x40/0xf0 do_el0_svc+0x24/0x40 el0_svc+0x40/0x1d0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00) ---[ end trace 0000000000000000 ]--- Also the reporter is very kind to test the following ASSERT() added to btrfs_trim_free_extents_throttle(): \tASSERT(device->bdev, \t \"devid=%llu path=%s dev_state=0x%lx\\n\", \t device->devid, btrfs_dev_name(device), device->dev_state); And it shows the following output: assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82) Which means the device->bdev is NULL, and the dev_state is BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without BTRFS_DEV_STATE_WRITEABLE flag set. [CAUSE] The pc points to the following call chain: btrfs_trim_fs() |- btrfs_trim_free_extents() |- btrfs_trim_free_extents_throttle() |- bdev_max_discard_sectors(device->bdev) So the NULL pointer dereference is caused by device->bdev being NULL. This looks impossible by a quick glance, as just before calling btrfs_trim_free_extents_throttle(), we have skipped any device that has BTRFS_DEV_STATE_MISSING flag set. However in this particular case, there is a window where the missing device is later re-scanned, causing btrfs to remove the BTRFS_DEV_STATE_MISSING flag: btrfs_control_ioctl() |- btrfs_scan_one_device() |- device_list_add() |- rcu_assign_pointer(device->name, name); | This updates the missing device's path to the new good path. | |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state) This removes the BTRFS_DEV_STATE_MISSING flag. This allows the missing device to re-appear and clear the BTRFS_DEV_STATE_MISSING flag. However the device still does not have the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated. The bdev pointer remains NULL, triggering the crash later. [FIX] This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and device->bdev pointer, and shows a gap in btrfs's re-appearing-device handling. The proper handling of re-appearing device will need quite some extra work, which is out of the context of this small ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64594", "url": "https://ubuntu.com/security/CVE-2026-64594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: initialize reset_work at allocation time ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on ffs->reset_work when a functionfs instance is unmounted: \tffs_data_reset(ffs); \tcancel_work_sync(&ffs->reset_work); However ffs->reset_work is only ever initialized via INIT_WORK() in ffs_func_set_alt() and ffs_func_disable(), and only on the FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed() when the instance is mounted with the \"no_disconnect\" option, so for the common case (no \"no_disconnect\", or mounted and unmounted without ever being deactivated) reset_work is never initialized. ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch it either, so reset_work.func is left NULL. cancel_work_sync() on such a work then trips the WARN_ON(!work->func) guard in __flush_work(): WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flush_work cancel_work_sync ffs_fs_kill_sb [usb_f_fs] deactivate_locked_super deactivate_super cleanup_mnt __cleanup_mnt task_work_run exit_to_user_mode_loop el0_svc On older kernels cancel_work_sync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization. Initialize reset_work once in ffs_data_new() so it is always valid for the lifetime of the ffs_data, and drop the now-redundant INIT_WORK() calls from the two deactivation paths.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68456", "url": "https://ubuntu.com/security/CVE-2026-68456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect() ueagle-atm uses the asynchronous request_firmware_nowait() in .probe(), but does not wait for its completion, not even in .disconnect(); so, if the device is unplugged meanwhile, its teardown runs concurrently with that. Even though this inconsistency is worth addressing on its own, it has also triggered several bug reports in syzbot over the years (some auto-closed) where the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER) creates a firmware subdirectory in the device directory during its removal, which might hit unexpected conditions in kernfs, apparently, depending at which point the add and remove operations raced. (See links.) The pattern is: usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2 usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw Call trace: ... kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs _request_firmware request_firmware_work_func ... (Some variations are observed, after fw_load_sysfs_fallback(), e.g., [1].) While the kernfs side is being looked at, the ueagle-atm side can be fixed by waiting for the pre-firmware load in the .disconnect() handler. This change has a similar approach to previous work by Andrey Tsygunka [2] (wait_for_completion() in .disconnect()), but it is relatively different in design/implementation; using the Originally-by tag for credit assignment. This has been tested with: - synthetic reproducer to check the error path; - USB gadget (virtual device) to check the firmware upload path; - QEMU device emulator to check the device ID re-enumeration path; (The latter two were written by Claude; no other code/text in this commit.) Links (year first reported): 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd4 2024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84d86f0d71394829df6fc53daf6642c045983881 2021 https://syzbot.org/bug?id=3302dc1c0e2b9c94f2e8edb404eabc9267bc6f90 [1] https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 [2] https://lore.kernel.org/lkml/20250410093146.3776801-2-aitsygunka@yandex.ru/", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-64329", "url": "https://ubuntu.com/security/CVE-2026-64329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled. The probe error path already orders free_irq() before ucsi_destroy(). This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64352", "url": "https://ubuntu.com/security/CVE-2026-64352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to \"c || rcu_read_lock_held()\", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64355", "url": "https://ubuntu.com/security/CVE-2026-64355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject fragmented frames in devmap Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64361", "url": "https://ubuntu.com/security/CVE-2026-64361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length check_and_correct_requested_length() compares (off + len) against node_size using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfs_brec_remove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail. For example, with off=14 and len=0xFFFFFFF2 (underflowed from data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6, which is less than a typical node_size of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer. Fix this by widening the addition to u64 before comparing against node_size. This prevents the u32 wrap while keeping the logic straightforward.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64363", "url": "https://ubuntu.com/security/CVE-2026-64363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: appleir: fix UAF on pending key_up_timer in remove() appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 (\"HID: appletb-kbd: fix UAF in inactivity-timer cleanup path\") and has been present since the driver was introduced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64371", "url": "https://ubuntu.com/security/CVE-2026-64371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (part 1) Fix the easy cases where procfs currently calls ptrace_may_access() without exec_update_lock protection, where the fix is to simply add the extra lock or use mm_access(): - do_task_stat(): grab exec_update_lock - proc_pid_wchan(): grab exec_update_lock - proc_map_files_lookup(): use mm_access() instead of get_task_mm() - proc_map_files_readdir(): use mm_access() instead of get_task_mm() - proc_ns_get_link(): grab exec_update_lock - proc_ns_readlink(): grab exec_update_lock", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64364", "url": "https://ubuntu.com/security/CVE-2026-64364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix out-of-bounds bit access on mt_io_flags mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG. As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs \tfor (i = 0; i < mt->num_slots; i++) \t\tclear_bit(i, &td->mt_io_flags); with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received). The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required. Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two \"mt_io_flags & MT_IO_SLOTS_MASK\" arming checks become bitmap_empty(td->active_slots, td->maxcontacts). Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64375", "url": "https://ubuntu.com/security/CVE-2026-64375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (FD links) proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways. To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link().", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64390", "url": "https://ubuntu.com/security/CVE-2026-64390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: track the connection owning a byte-range lock SMB2_LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llist_lock. With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbd_lock and struct file_lock objects. Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llist_lock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-31610", "url": "https://ubuntu.com/security/CVE-2026-31610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: \tif (conn->use_spnego && conn->mechToken) { \t\tkfree(conn->mechToken); \t\tconn->mechToken = NULL; \t} so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-64380", "url": "https://ubuntu.com/security/CVE-2026-64380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: harden POSIX SID length parsing posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64379", "url": "https://ubuntu.com/security/CVE-2026-64379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: mask server-provided mode to 07777 in modefromsid When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64401", "url": "https://ubuntu.com/security/CVE-2026-64401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: resolve SWN tcon from live registrations cifs_swn_notify() looks up a witness registration by id under cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifs_get_swn_reg() lets multiple tcons for the same net/share name share one registration id. A same-share second mount can keep the cifs_swn_reg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tc_lock or incrementing tc_count through swnreg->tcon only moves the use-after-free earlier. Taking tc_lock while holding cifs_swnreg_idr_mutex also violates the documented CIFS lock order. Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifs_tcp_ses_lock -> tc_lock order. The notification path uses that pinned tcon directly and drops the reference when done. Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifs_swn_unregister() while the registration is still protected by cifs_swnreg_idr_mutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings. This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENT_MOVE ordering for the representative tcon because the old-IP unregister is sent before cifs_swn_register() sends the new-IP register.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64381", "url": "https://ubuntu.com/security/CVE-2026-64381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix next buffer leak in receive_encrypted_standard() receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64206", "url": "https://ubuntu.com/security/CVE-2026-64206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64413", "url": "https://ubuntu.com/security/CVE-2026-64413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: zero chainstack array sashiko reports: looking at ebtables table translation, could a sparse cpu_possible_mask lead to an uninitialized pointer free? If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1]. Not a real-world bug, such allocation isn't expected to fail in the first place.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64428", "url": "https://ubuntu.com/security/CVE-2026-64428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: sch: use raw_spinlock_t in the irq startup path sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64438", "url": "https://ubuntu.com/security/CVE-2026-64438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix VF2PF work teardown race in adf_disable_sriov() The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adf_accel_vf_info). Currently, adf_disable_sriov() destroys per-VF mutexes and frees vf_info without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory. This manifests as a use-after-free when KASAN is enabled: BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] Call Trace: kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vf_info is destroyed. Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64441", "url": "https://ubuntu.com/security/CVE-2026-64441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr() Three IE/attribute parsing functions have missing bounds checks. rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtw_get_sec_ie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain. rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at entry, before verifying that wps_ielen is large enough to contain the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside the attribute loop, get_unaligned_be16() is called on attr_ptr and attr_ptr+2 without checking that 4 bytes remain in the buffer. Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie() and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum IE length requirement, add a wps_ielen < 6 early return in rtw_get_wps_attr(), and add a 4-byte bounds check in its inner loop.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64461", "url": "https://ubuntu.com/security/CVE-2026-64461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64446", "url": "https://ubuntu.com/security/CVE-2026-64446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie() supplicant_ie is a 256-byte array in struct security_priv. The WPA and WPA2 IE copy paths use: memcpy(padapter->securitypriv.supplicant_ie, &pwpa[0], wpa_ielen + 2); where wpa_ielen is the raw IE length field (u8, 0-255). When a local user supplies a connect request via nl80211 with a crafted WPA IE of length 255, wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into the adjacent last_mic_err_time field. rtw_parse_wpa_ie() does not prevent this: its length consistency check compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255 when wpa_ie_len = 257, so the check passes silently. Add explicit bounds checks for both the WPA and WPA2 paths before the memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the supplicant_ie buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64448", "url": "https://ubuntu.com/security/CVE-2026-64448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: restrict implied bcc[0] exemption to responses without data area smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received (\"server can return one byte more due to implied bcc[0]\"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, yet smb2_check_message() still accepts it. The subsequent decoder then reads past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server; both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders are affected: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00 Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81 CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 asn1_ber_decoder+0x16a7/0x1b00 decode_negTokenInit+0x19/0x30 SMB2_negotiate+0x31d9/0x4c90 cifs_negotiate_protocol+0x1f2/0x3f0 cifs_get_smb_ses+0x93f/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 85: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 0 bytes to the right of allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0) which belongs to the cache cifs_small_rq of size 448 BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50 Read of size 329 at addr ffff88800726c678 by task mount.cifs/89 CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x36/0x50 decode_ntlmssp_challenge+0x457/0x680 SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0 SMB2_sess_setup+0x219/0x4f0 cifs_setup_session+0x248/0xaf0 cifs_get_smb_ses+0xf79/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 93: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 120 bytes inside of allocated 448-byte region [ffff88800726c600, ffff88800726c7c0) which belongs to the cache cifs_small_rq of size 448 Restrict the +1 exemption to responses that have no data area, so that it still covers the bcc[0] omission it was meant for. When a data area is present, the +1 discrepancy instead means the reported data length overruns the ---truncated---", "cve_priority": "negligible", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64462", "url": "https://ubuntu.com/security/CVE-2026-64462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64475", "url": "https://ubuntu.com/security/CVE-2026-64475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Release the VGA arbiter client on register_device() failure The re-order in the Fixes commit below displaced vfio_pci_vga_init() as the last failure point of what is now vfio_pci_core_register_device() without introducing an unwind for the VGA arbiter registration. In current kernels this is mostly benign because vfio_pci_set_decode() only uses pci_dev state, but the original failure path could leave a callback with a freed vdev cookie. The stale registration also becomes unsafe again once the callback follows drvdata to the vfio device. Add the required VGA unwind callout.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64488", "url": "https://ubuntu.com/security/CVE-2026-64488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return early if any fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64510", "url": "https://ubuntu.com/security/CVE-2026-64510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64512", "url": "https://ubuntu.com/security/CVE-2026-64512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Suppress UBSAN warning caused by field misuse The definition of reg->access_width changes depending on the reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses access_width to indicate the PCC region, which can result in a UBSAN if the value is greater than 4. For example: UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9 shift exponent 32 is too large for 32-bit type 'int' CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy) Hardware name: To be filled by O.E.M. Call trace: ...(trimming) ubsan_epilogue+0x10/0x48 __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ... (trimming) Lets fix this by validating the region type, as well as whether access_width has a value. Then since we are returning bit_width directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting the size.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68466", "url": "https://ubuntu.com/security/CVE-2026-68466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68467", "url": "https://ubuntu.com/security/CVE-2026-68467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mchp23k256: use SPI match data for chip caps The driver stores chip capacity information in both the OF match table and the SPI id table. Probe currently uses of_device_get_match_data(), so a non-OF SPI modalias match falls back to mchp23k256_caps even when the SPI id table selected a different part. Use spi_get_device_match_data() so SPI id-table driver_data is consumed when OF match data is absent. This keeps the existing default fallback while avoiding the wrong MTD geometry for id-table-only matches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68469", "url": "https://ubuntu.com/security/CVE-2026-68469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix permanently busy scans after multiple roam iterations In order for the firmware to sleep, the driver has to confirm a previously received sleep request. The normal sequence of evets goes like this: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Before sending the sleep-confirm command, the driver must make sure there are no commands either running or waiting to be completed. mwifiex_ret_802_11_associate() unconditionally sets ps_state = PS_STATE_AWAKE when it processes the association command response, outside of the normal powersave management flow. If EVENT_SLEEP arrives while the association command is in flight, ps_state is PRE_SLEEP when the association command response is parsed, and the forced AWAKE overwrites it. The deferred sleep-confirm is never sent. A subsequent scan_start command is correctly acknowledged, but the firmware doesn't generate scan_result events. The scan request never finishes, and additional requests from userspace fail with -EBUSY. After testing on both IW412 and W8997, I could only trigger the bug on the IW412 and observed the firmwares behave differently. On the IW412 the firmware still sends EVENT_SLEEP while the authentication / association process is ongoing. A W8997 under the same conditions seems to suppress power-save for the duration of the association, so PRE_SLEEP never coincided with the association response even after extended periods of testing using the loops described below (>12hours). On the IW412, the delay between commands that triggers an EVENT_SLEEP was empirically determined to be ~20ms. This delay can naturally occur when the driver is outputting debugging information (debug_mask = 0x00000037), in which situation the busy scans issue is repeatable while running \"test 1)\" as described below. If the delay between commands is less than ~20ms, the firmware stays awake and the issue was not reproducible running the same test. The host_mlme=false path also behaves differently. In this case, the entire authentication / association transaction is executed by one command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit EVENT_SLEEP while the command is running. Remove the assignment so the ps_state is only manipulated in the paths that are related to powersave event handling and on the main workqueue for correct sleep confirmation. The following loop tests were performed (with debugging output enabled): 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations. Each test ran in each device for at least 3 hours.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68474", "url": "https://ubuntu.com/security/CVE-2026-68474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access() spufs_mem_mmap_access() computes the local store offset as address - vma->vm_start, but bounds-checks it against vma->vm_end instead of the local store size. On 64-bit, offset is always well below vma->vm_end, so the clamp never fires and len stays unbounded against the LS_SIZE buffer returned by ctx->ops->get_ls(). Reject offsets at or beyond LS_SIZE and clamp len to the remaining space, mirroring the guard already used by spufs_mem_mmap_fault() and spufs_ps_fault().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68475", "url": "https://ubuntu.com/security/CVE-2026-68475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: reset: sunxi: fix memory region leak on ioremap failure In sunxi_reset_init(), when ioremap() fails, the memory region obtained via request_mem_region() is not released, leading to a resource leak. Add an err_mem_region label to properly release the memory region before freeing the data structure.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68478", "url": "https://ubuntu.com/security/CVE-2026-68478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memstick: ms_block: reject a card that reports too many blocks msb_ftl_initialize() computes the zone count from the card block count with no bound: \tmsb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; \t... \tfor (i = 0; i < msb->zone_count; i++) \t\tmsb->free_block_count[i] = MS_BLOCKS_IN_ZONE; msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the init loop past the end too. A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68479", "url": "https://ubuntu.com/security/CVE-2026-68479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: validate firmware patch bounds rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup. The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72004", "url": "https://ubuntu.com/security/CVE-2026-72004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix memory leak in ieee80211_register_hw() If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl. Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72005", "url": "https://ubuntu.com/security/CVE-2026-72005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: avoid full teardown before work setup in probe rt2x00lib_probe_dev() uses the full rt2x00lib_remove_dev() teardown for all probe failures. However, drv_data allocation and workqueue allocation can fail before intf_work, autowakeup_work and sleep_work have been initialized. Do not enter the full remove path until the probe has reached the point where those work items are set up. Return directly for drv_data allocation failure, and use a small early cleanup path for workqueue allocation failure. This issue was found by our static analysis tool and then confirmed by manual review of rt2x00lib_probe_dev() and rt2x00lib_remove_dev(). The early probe exits should not call a common teardown path that assumes the later work setup has already completed. A QEMU PoC forced alloc_ordered_workqueue() to fail before the work initializers are reached. The resulting fail path entered rt2x00lib_remove_dev(), and DEBUG_OBJECTS reported invalid work drains with rt2x00lib_probe_dev() and rt2x00lib_remove_dev() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72010", "url": "https://ubuntu.com/security/CVE-2026-72010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72013", "url": "https://ubuntu.com/security/CVE-2026-72013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent NULL pointer dereference in machine_kexec_prepare() A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72021", "url": "https://ubuntu.com/security/CVE-2026-72021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in SCTP state lookup set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header. This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed. Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72022", "url": "https://ubuntu.com/security/CVE-2026-72022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: llc: fix SAP refcount leak in llc_ui_autobind() llc_ui_autobind() opens a SAP after choosing a dynamic LSAP. llc_sap_open() returns a reference owned by the caller, and llc_sap_add_socket() takes a second reference for the socket's membership in the SAP hash tables. llc_ui_bind() drops the caller's reference after adding the socket, but llc_ui_autobind() keeps it. When the socket is closed, llc_sap_remove_socket() releases only the socket reference, leaving the SAP on llc_sap_list with sk_count == 0. This is user-visible because repeated autobind and close cycles can consume all dynamic SAP values and make later autobinds fail with -EUSERS. Drop the caller's reference after a successful autobind, matching llc_ui_bind()'s ownership model.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72024", "url": "https://ubuntu.com/security/CVE-2026-72024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: remove interfaces with RCU list deletion Queue wake, stop, and disable paths walk local->interfaces under RCU. The bulk hardware teardown path removes entries with list_del(), so an asynchronous transmit completion can follow a poisoned list node in ieee802154_wake_queue(). Use list_del_rcu() as in the single-interface removal path. The following unregister_netdevice() waits for in-flight RCU readers before freeing the netdevice, so no separate grace-period wait is needed.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72025", "url": "https://ubuntu.com/security/CVE-2026-72025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/monwriter: Reject buffer reuse with different data length When data buffers are reused, e.g. for interval sample records, the first record determines the data length, and the size of the buffer for user copy. Current monwriter code does not check if the data length was changed for subsequent records, which also would never happen for valid user programs. However, a malicious user could change the data length, resulting in out of bounds user copy to the kernel buffer, and memory corruption. By default, the monwriter misc device is created with root-only permissions, so practical impact is typically low. Fix this by checking for changed data length and rejecting such records.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72036", "url": "https://ubuntu.com/security/CVE-2026-72036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked multiq_dequeue() takes a packet from a band's child with a direct ->dequeue() call after multiq_peek() peeked it. When the child is non-work-conserving the peek stashes the skb in the child's gso_skb, so the direct dequeue returns a different skb and orphans the stash, desyncing the child's qlen/backlog. With a qfq child reached through a peeking parent (e.g. tbf) this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_prio already does and as sch_red and sch_sfb were just fixed to do. The helper is a no-op when the child has no stash, so a work-conserving child is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72038", "url": "https://ubuntu.com/security/CVE-2026-72038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: fix BAR resource leak on PF number failure If cn23xx_get_pf_num() fails, the function returns without unmapping either BAR. Unmap both BARs before returning from the error path. Found by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72039", "url": "https://ubuntu.com/security/CVE-2026-72039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72229", "url": "https://ubuntu.com/security/CVE-2026-72229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: clean untagged VLAN on netdev registration failure When an mesh interface is registered, it creates an untagged struct batadv_meshif_vlan on top of it via the NETDEV_REGISTER notifier. But in this process, another receiver of this notification can veto the registration. The netdev registration will be aborted because of this veto. The register_netdevice() call will try to clean up the net_device using unregister_netdevice_queue() - which only uses the .priv_destructor to free private resources. In this situation, .dellink will not be called. The cleanup of the untagged batadv_meshif_vlan must thefore be done in the destructor to avoid a leak of this object.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72232", "url": "https://ubuntu.com/security/CVE-2026-72232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: ensure minimal ethernet header on TX As documented in commit 8bd67ebb50c0 (\"net: bridge: xmit: make sure we have at least eth header len bytes\"), it is possible by for a local user with eBPF TC hook access to attach a tc filter which truncates the packet and redirects to an batadv interface. But the code assumes that at least ETH_HLEN bytes are available and thus might read outside of the available buffer. The batadv_interface_tx() must therefore always check itself if enough data is available for the ethernet header and don't rely on min_header_len.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72235", "url": "https://ubuntu.com/security/CVE-2026-72235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: retrieve ethhdr after potential skb realloc on RX pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72047", "url": "https://ubuntu.com/security/CVE-2026-72047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72048", "url": "https://ubuntu.com/security/CVE-2026-72048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix cas_ctl leak on spi_async failure ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72049", "url": "https://ubuntu.com/security/CVE-2026-72049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: admin-gate legacy LLSEC dump operations In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM. Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the \"802.15.4 MAC\" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames. Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family. Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry \"can be retrieved by unprivileged users\" annotations).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72052", "url": "https://ubuntu.com/security/CVE-2026-72052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72054", "url": "https://ubuntu.com/security/CVE-2026-72054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72055", "url": "https://ubuntu.com/security/CVE-2026-72055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink vti6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72056", "url": "https://ubuntu.com/security/CVE-2026-72056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ena: clean up XDP TX queues when regular TX setup fails create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72061", "url": "https://ubuntu.com/security/CVE-2026-72061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sit: require CAP_NET_ADMIN in the device netns for changelink ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72066", "url": "https://ubuntu.com/security/CVE-2026-72066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Bound hotplug states sysfs output states_show() adds CPU hotplug state names into a single sysfs buffer using sprintf(). With enough registered states, this can write past the end of the PAGE_SIZE buffer. Use sysfs_emit_at() so output is bounded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72067", "url": "https://ubuntu.com/security/CVE-2026-72067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Preserve per instance callback errors cpuhp_invoke_callback() unwinds earlier callbacks for the same hotplug state when one instance fails. The rollback path currently reuses ret, so a successful rollback can hide the original error and make the failed transition look successful. Keep the rollback result separate from the original error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72074", "url": "https://ubuntu.com/security/CVE-2026-72074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix type confusion in CDC union descriptor parsing The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72076", "url": "https://ubuntu.com/security/CVE-2026-72076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72078", "url": "https://ubuntu.com/security/CVE-2026-72078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - validate control endpoint type The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72079", "url": "https://ubuntu.com/security/CVE-2026-72079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix use-after-free and double-free in disconnect ims_pcu_disconnect() only intended to perform cleanup when the primary (control) interface is unbound. However, it currently relies on the interface class to distinguish between control and data interfaces. A malicious device could present a data interface with the same class as the control interface, leading to premature cleanup and potential use-after-free or double-free. Switch to verifying that the interface being disconnected is indeed the control interface.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72081", "url": "https://ubuntu.com/security/CVE-2026-72081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix I/O leak on unsupported additional CDB efct_dispatch_fcp_cmd() allocates an efct_io before dispatching an unsolicited FCP command. If the command has an unsupported additional CDB, the function returns -EIO before handing the IO to the SCSI layer. Free the allocated IO before returning from this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72082", "url": "https://ubuntu.com/security/CVE-2026-72082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix refcount leak in efct_hw_io_abort() When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object. Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery. Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72086", "url": "https://ubuntu.com/security/CVE-2026-72086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free the command tag on the TMR submit-failure path scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag. Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails. transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req. Use the same helper, which returns just the tag, on this path too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72088", "url": "https://ubuntu.com/security/CVE-2026-72088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72102", "url": "https://ubuntu.com/security/CVE-2026-72102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm_early_create: fix freeing used table on dm_resume failure If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72105", "url": "https://ubuntu.com/security/CVE-2026-72105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-log: fix a bitset_size overflow on 32bit machines Commit c20e36b7631d (\"dm log: fix out-of-bounds write due to region_count overflow\") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72107", "url": "https://ubuntu.com/security/CVE-2026-72107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix out-of-bounds memory access for non-zero start sector dm-era tracks writes in target-relative blocks, but era_map() calculates the writeset block before applying the target offset. Tables with a non-zero start sector can therefore pass an absolute mapped-device block to metadata_current_marked(). If the absolute block is beyond the current writeset size, writeset_marked() tests past the end of the in-core bitset. KASAN reports this as a vmalloc-out-of-bounds access. Apply the target offset before calculating the era block so writeset lookups use the target-relative block number.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72108", "url": "https://ubuntu.com/security/CVE-2026-72108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm thin metadata: fix metadata snapshot consistency on commit failure __reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata. Reproducer 1: __reserve_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 112 linear /dev/sdc 0 112 3984 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency. dmsetup message tpool 0 \"reserve_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0. Reproducer 2: __release_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 128 linear /dev/sdc 0 128 3968 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata. dmsetup message tpool 0 \"reserve_metadata_snap\" dmsetup message tpool 0 \"release_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked. Fix by deferring the held_root update to commit time. Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72109", "url": "https://ubuntu.com/security/CVE-2026-72109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sparx5: unregister blocking notifier on init failure sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72120", "url": "https://ubuntu.com/security/CVE-2026-72120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu list annotations and operations sashiko-bot remarked the missing use of list_add_rcu() in bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure when bcm_proc_show() traverses the bcm_op's under rcu_read_lock(). To cover all initial settings of the bcm_op's the list_add_rcu() calls are moved to the end of the setup code. While at it, also fix the mirroring removal side: bcm_release() called bcm_remove_op() - which frees the op via call_rcu() - on ops that were still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first. Unlink each op with list_del_rcu() before handing it to bcm_remove_op(), matching the existing pattern in bcm_delete_tx_op()/bcm_delete_rx_op().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72122", "url": "https://ubuntu.com/security/CVE-2026-72122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all mutate both fields under that same lock. Because the lockless reads and the locked writes are unordered with respect to each other, a racing bcm_notify() (device unregister) or bcm_connect() (concurrent bind on another thread sharing the socket) can make bcm_sendmsg() observe an inconsistent combination, e.g. a stale bound=1 together with the now-cleared ifindex=0, silently turning a socket bound to a specific CAN interface into one that also matches \"any\" interface. Keep the lockless bo->bound check purely as a fast-path reject, and move the ifindex read (and a bo->bound re-check) into the locked section, where every writer already serializes. This removes the possibility of observing the two fields torn against each other, rather than trying to fix it with more READ_ONCE()/WRITE_ONCE() pairs on two independently updated fields. Annotate the now-purely-lockless bo->bound accesses consistently across all its write sites. Also fix bcm_rx_setup() silently returning success when the target device disappears concurrently instead of reporting -ENODEV, so a broken RX op is no longer left registered as if it had succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72126", "url": "https://ubuntu.com/security/CVE-2026-72126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72133", "url": "https://ubuntu.com/security/CVE-2026-72133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: Fix completion initialization order before devm_request_irq() The driver calls devm_request_irq() before initializing the completion used by the interrupt handler. Because the interrupt may occur immediately after devm_request_irq(), the handler may execute before init_completion(). This may result in calling complete() on an uninitialized completion, causing undefined behavior. This has been observed with KASAN. Fix this by initializing the completion before registering the IRQ.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72135", "url": "https://ubuntu.com/security/CVE-2026-72135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Make the TPM character devices non-seekable The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset(). Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale. Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged. Tested on Linux 6.12 with KASAN and a swtpm TPM2 device: - sequential partial reads returned the complete response - pread() and preadv() with offset 0x1400 returned -ESPIPE - pwrite() and pwritev() with offset zero returned -ESPIPE - the pending response remained intact after the rejected operations - a subsequent normal command/response cycle completed normally - no KASAN report was produced.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72136", "url": "https://ubuntu.com/security/CVE-2026-72136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72138", "url": "https://ubuntu.com/security/CVE-2026-72138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Fix these issues by properly handling all error cases.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72140", "url": "https://ubuntu.com/security/CVE-2026-72140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource() If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72153", "url": "https://ubuntu.com/security/CVE-2026-72153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72159", "url": "https://ubuntu.com/security/CVE-2026-72159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72160", "url": "https://ubuntu.com/security/CVE-2026-72160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series \"ocfs2: harden inode validators against forged metadata\", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72163", "url": "https://ubuntu.com/security/CVE-2026-72163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72164", "url": "https://ubuntu.com/security/CVE-2026-72164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: avoid moving extents to occupied clusters For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group. The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated. When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run. Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72165", "url": "https://ubuntu.com/security/CVE-2026-72165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: fix condition in 'nand_select_target()' 'cs' here must be in range [0:nanddev_ntargets[.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72166", "url": "https://ubuntu.com/security/CVE-2026-72166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: \terr = io_wait_event_killable(req->wq, ...) \t/* SIGKILL wakes the task, returns -ERESTARTSYS */ \tif (err == -ERESTARTSYS && c->status == Connected && \t\ttype == P9_TFLUSH) { \t\tsigpending = 1; \t\tclear_thread_flag(TIF_SIGPENDING); \t\tgoto again; \t} clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72167", "url": "https://ubuntu.com/security/CVE-2026-72167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72171", "url": "https://ubuntu.com/security/CVE-2026-72171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: slram: remove failed entries from the device list register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72181", "url": "https://ubuntu.com/security/CVE-2026-72181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mips: sched: Fix CPUMASK_OFFSTACK memory corruption This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72182", "url": "https://ubuntu.com/security/CVE-2026-72182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: fix refcount leak in is_full_charged() In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72193", "url": "https://ubuntu.com/security/CVE-2026-72193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: cap RESTART_TABLE free-chain walker at rt->used A crafted NTFS3 disk image triggers an in-kernel infinite loop at mount time, hanging the mounting thread and firing the soft-lockup watchdog within ~22s on multi-CPU hosts (panic with kernel.softlockup_panic=1). The bug is reachable from desktop USB auto-mount on distributions where udisks2 routes the NTFS signature to the in-tree ntfs3 driver (Arch family and an increasing fraction of Fedora / openSUSE / RHEL deployments); CAP_SYS_ADMIN-class manual mount elsewhere. check_rstbl()'s second walker iterates the free-entry singly-linked list headed by rt->first_free with no upper bound on iteration count: for (off = ff; off;) { if (off == RESTART_ENTRY_ALLOCATED) return false; off = le32_to_cpu(*(__le32 *)Add2Ptr(rt, off)); if (off > ts - sizeof(__le32)) return false; } The existing guards cover three exits: end-of-list (off == 0), the in-use marker (off == RESTART_ENTRY_ALLOCATED), and out-of-bounds (off > ts - sizeof(__le32)). None of the three prevents an in-bounds cycle. A crafted on-disk RESTART_TABLE whose free chain contains a self-loop or A->B->A cycle whose offsets satisfy: - in range [sizeof(struct RESTART_TABLE), ts - sizeof(__le32)] - (off - sizeof(struct RESTART_TABLE)) % rsize == 0 passes all existing guards and spins the mount-time thread forever. Reproduced in UML by hand-forging a 2 MB NTFS3 image whose journal RESTART_TABLE first_free = 0x18 and whose entry at offset 0x18 stores 0x18 as its next pointer; mount of the forged image with the in-tree ntfs3 driver never returns. Bound the walker by rt->used. Each entry on a legitimate free chain is unique, and the total slot count is ne = le16_to_cpu (rt->used). A traversal that visits more than ne slots is by construction malformed; reject it as a corrupt RESTART_TABLE. After this patch, mount of the forged image returns with -EINVAL and a log_replay failure message, and mkntfs-produced legitimate images mount cleanly (verified in the same UML harness).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64532", "url": "https://ubuntu.com/security/CVE-2026-64532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation} In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is `Add2Ptr(e, le16_to_cpu(e->view.data_off))`, where e->view.data_off comes from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validates view.data_off + dlen against e->size; the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate the entry's offset, but not its internal view fields. The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <= e->size. Apply the same bound at the two memmove sites. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE. This is similar in shape to Pavitra Jha's 2026-05-02 patch \"fs/ntfs3: prevent oob in case UpdateRecordDataRoot\" (<20260502105008.21827-1-jhapavitra98@gmail.com>) which proposes calling ntfs3_bad_de_range(); that helper does not exist in mainline. This patch uses inline checks.", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64533", "url": "https://ubuntu.com/security/CVE-2026-64533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate lcns_follow in log_replay conversion log_replay() converts DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY records when replaying version 0 restart tables. During this conversion, the memmove() length is derived directly from the on-disk lcns_follow field: \tmemmove(&dp->vcn, &dp0->vcn_low, \t\t2 * sizeof(u64) + \t\t\t\tle32_to_cpu(dp->lcns_follow) * sizeof(u64)); check_rstbl() validates restart table structure, but does not constrain per-entry lcns_follow values relative to the entry size. A malformed filesystem image can provide an oversized lcns_follow value, causing the conversion memmove() to access memory beyond the bounds of the allocated restart table buffer. The same field is later used to bound iteration over page_lcns[], so validating lcns_follow during conversion also prevents downstream out-of-bounds access from the same malformed metadata. Compute the maximum valid lcns_follow from the already-validated restart table entry size and reject entries that exceed this bound. Reuse the existing t16/t32 scratch variables already declared in log_replay() to avoid introducing new declarations. [almaz.alexandrovich@paragon-software.com: fixed the conflicts]", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72195", "url": "https://ubuntu.com/security/CVE-2026-72195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment \tattr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72197", "url": "https://ubuntu.com/security/CVE-2026-72197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: \tif (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || \t Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || \t used + esize > le32_to_cpu(hdr->total)) { \t\tgoto dirty_vol; \t} Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72215", "url": "https://ubuntu.com/security/CVE-2026-72215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002. To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant. Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and \"if it ain't broke, don't fix it,\" so just leave them alone.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72218", "url": "https://ubuntu.com/security/CVE-2026-72218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72219", "url": "https://ubuntu.com/security/CVE-2026-72219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file leak when nlm_do_fopen() fails A client can repeatedly drive nlm_do_fopen() failures by presenting file handles that the underlying export rejects. After kzalloc_obj() succeeds in nlm_lookup_file(), the freshly allocated nlm_file is not yet inserted into nlm_files[]. The nlm_do_fopen() failure path jumps to out_unlock, which releases nlm_file_mutex and returns without freeing the allocation, so each failure leaks one nlm_file. Route the failure through out_free so kfree() runs before the function returns.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72223", "url": "https://ubuntu.com/security/CVE-2026-72223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arena sub-allocations on discover_arenas() error path Memory allocated by btt_freelist_init(), btt_rtt_init(), and btt_maplocks_init() is not freed on some discover_arenas() error paths. This leaks memory when arena discovery fails. Add the missing kfree() calls to release the allocations before returning an error. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72224", "url": "https://ubuntu.com/security/CVE-2026-72224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arenas on btt_init() error paths The arenas allocated by discover_arenas() or create_arenas() are not freed on some error paths in btt_init(). This leaks memory when BTT initialization fails. Call free_arenas() from the affected error paths to release the allocations. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72225", "url": "https://ubuntu.com/security/CVE-2026-72225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit() jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check. The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort. Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72228", "url": "https://ubuntu.com/security/CVE-2026-72228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: fix primary_if leak on failed linearization If the skb has a frag_list, it must be linearized before it can be split using skb_split(). But when this step failed, it must not only free the skb but also take care of the reference to the already found primary_if.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72230", "url": "https://ubuntu.com/security/CVE-2026-72230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72231", "url": "https://ubuntu.com/security/CVE-2026-72231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is \"ret == false\". But the actual implementation is checking for \"ret == true\". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72233", "url": "https://ubuntu.com/security/CVE-2026-72233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: reacquire gw address after skb realloc The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72238", "url": "https://ubuntu.com/security/CVE-2026-72238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/boot: Validate console=uart8250 baud rate to fix early boot hang When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72240", "url": "https://ubuntu.com/security/CVE-2026-72240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72241", "url": "https://ubuntu.com/security/CVE-2026-72241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: uleds: Fix potential buffer overread The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72245", "url": "https://ubuntu.com/security/CVE-2026-72245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64554", "url": "https://ubuntu.com/security/CVE-2026-64554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() br_ip6_fragment() gets prevhdr, a pointer into the skb head, from ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb skb_checksum_help() reallocates the head via pskb_expand_head(), leaving prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a use-after-free write. Save prevhdr's offset before skb_checksum_help() and recompute it after, like commit ef0efcd3bd3f (\"ipv6: Fix dangling pointer when ipv6 fragment\"). BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857) Write of size 1 at addr ffff888013ff5016 by task exploit/141 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip6_frag_next (net/ipv6/ip6_output.c:857) br_ip6_fragment (net/ipv6/netfilter.c:212) nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407) nf_hook_slow (net/netfilter/core.c:619) br_forward_finish (net/bridge/br_forward.c:66) __br_forward (net/bridge/br_forward.c:115) maybe_deliver (net/bridge/br_forward.c:191) br_flood (net/bridge/br_forward.c:245) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:442) ... packet_sendmsg (net/packet/af_packet.c:3114) ... do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72247", "url": "https://ubuntu.com/security/CVE-2026-72247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: fix zone comparison in tuple dedup The \"already exists\" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument. Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone. nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents. Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72250", "url": "https://ubuntu.com/security/CVE-2026-72250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header: \tskb->mac_header += sizeof(struct frag_hdr); On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the \"not set\" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom. The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72256", "url": "https://ubuntu.com/security/CVE-2026-72256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_cluster: reject template conntracks in hash match xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72264", "url": "https://ubuntu.com/security/CVE-2026-72264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tridentfb: fix potential memory leak in trident_pci_probe() In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72265", "url": "https://ubuntu.com/security/CVE-2026-72265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: nvidia: fix potential memory leak in nvidiafb_probe() In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72267", "url": "https://ubuntu.com/security/CVE-2026-72267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: carminefb: fix potential memory leak in alloc_carmine_fb() The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72268", "url": "https://ubuntu.com/security/CVE-2026-72268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe() In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72269", "url": "https://ubuntu.com/security/CVE-2026-72269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: fix potential memory leak in uvesafb_probe() Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. Fix this by updating the goto label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72270", "url": "https://ubuntu.com/security/CVE-2026-72270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: s3fb: fix potential memory leak in s3_pci_probe() In s3_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72271", "url": "https://ubuntu.com/security/CVE-2026-72271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: i740fb: fix potential memory leak in i740fb_probe() In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72272", "url": "https://ubuntu.com/security/CVE-2026-72272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: radeon: fix potential memory leak in radeonfb_pci_register() The function radeonfb_pci_register() allocates memory for modelist (by calling radeon_check_modes() which calls fb_add_videomode()). The memory is appended to info->modelist, but is not freed in subsequent error paths. Fix this by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72274", "url": "https://ubuntu.com/security/CVE-2026-72274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: hecubafb: fix potential memory leak in hecubafb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72275", "url": "https://ubuntu.com/security/CVE-2026-72275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72276", "url": "https://ubuntu.com/security/CVE-2026-72276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: metronomefb: fix potential memory leak in metronomefb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72297", "url": "https://ubuntu.com/security/CVE-2026-72297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72298", "url": "https://ubuntu.com/security/CVE-2026-72298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with \tif (!size || len != ALIGN(size, 4) + hdrlen) \t\tgoto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 (\"net: qrtr: fix OOB Read in qrtr_endpoint_post\"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72306", "url": "https://ubuntu.com/security/CVE-2026-72306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72307", "url": "https://ubuntu.com/security/CVE-2026-72307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree. Fix by reinitializing vr inside the error loop with the updated index: \tvr = &mlxsw_sp->router->vrs[i]; so that the loop correctly iterates over all VRs that were actually replaced.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72310", "url": "https://ubuntu.com/security/CVE-2026-72310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds.", "cve_priority": "negligible", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72314", "url": "https://ubuntu.com/security/CVE-2026-72314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72316", "url": "https://ubuntu.com/security/CVE-2026-72316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix NULL pointer dereference in metadata_open() metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72326", "url": "https://ubuntu.com/security/CVE-2026-72326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cake: reject overhead values that underflow length CAKE accepts signed overhead values and stores them in an s16, but the adjusted packet length calculation uses unsigned arithmetic. A negative effective length can therefore wrap to a large value. Such configurations make rate accounting depend on integer wraparound rather than on the packet size userspace intended to model. A static netlink lower bound is not enough because packets reaching CAKE can be smaller than any reasonable manual-overhead allowance. Fold the signed overhead adjustment into the existing datapath MPU clamp so negative adjusted lengths are clamped before link-layer framing adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64549", "url": "https://ubuntu.com/security/CVE-2026-64549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup() bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length: \tbt_dev_info(hdev, \"%s\", (char *)(skb->data + 1)); \thci_set_fw_info(hdev, \"%s\", skb->data + 1); A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file. Print the revision string with a bounded \"%.*s\" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64550", "url": "https://ubuntu.com/security/CVE-2026-64550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: validate MAP frame length before ingress parsing When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes the skb straight to __rmnet_map_ingress_handler(), skipping the length validation that rmnet_map_deaggregate() performs on the aggregated path. The parser then dereferences the MAP header and csum header/trailer based on the on-wire pkt_len without checking skb->len, so a short frame is read out of bounds: BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet Read of size 1 at addr ffff88801118ed00 by task exploit/147 Call Trace: ... rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413) __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089) netif_receive_skb (net/core/dev.c:6460) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2001) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Factor that validation out of rmnet_map_deaggregate() into rmnet_map_validate_packet_len() and run it on the no-aggregation path too. The MAP header is bounds-checked first, since this path can receive a frame shorter than the header.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72347", "url": "https://ubuntu.com/security/CVE-2026-72347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_connmark: reject invalid shift parameters Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmark_tg_shift(). A shift_bits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shift_dir values are also accepted and silently fall back to the left-shift path. Reject invalid revision-2 shift parameters in connmark_tg_check() so malformed rules fail at installation time, before they can reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72349", "url": "https://ubuntu.com/security/CVE-2026-72349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt() On links faster than ~34 Gbps, where byte rate may exceed 2^32-1 (~ 4.3 GBps), the comparison result becomes incorrect because the truncated value no longer reflects the actual estimator rate. Fix by changing the local variables to u64.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72350", "url": "https://ubuntu.com/security/CVE-2026-72350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_u32: reject invalid shift counts u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation. Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64547", "url": "https://ubuntu.com/security/CVE-2026-64547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: net1080: validate packet_len before pad-byte access in rx_fixup For an even packet_len, net1080_rx_fixup() reads the pad byte at skb->data[packet_len] before the skb->len != packet_len check further down, and packet_len is only bounded against NC_MAX_PACKET. A malicious NetChip 1080 device can send a short frame advertising a large even packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the skb: BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14 ... net1080_rx_fixup (drivers/net/usb/net1080.c:384) usbnet_bh (drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3708) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) ... Reject the frame when packet_len >= skb->len before reading.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72371", "url": "https://ubuntu.com/security/CVE-2026-72371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the volume AFS_VOLUME_RM_TREE is set on Fix afs_insert_volume_into_cell() to set AFS_VOLUME_RM_TREE on the volume replaced, not the new volume, as it's now removed from the cell's volume tree. This will cause the old volume to be removed from the tree twice and the new volume never to be removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72374", "url": "https://ubuntu.com/security/CVE-2026-72374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix callback service message parsers to pass through -EAGAIN The AFS filesystem client uses an rxrpc server to listen for callback notifications. Each callback call type handler has a delivery function that parses the incoming request stream, and this should return -EAGAIN the last packet hasn't yet been seen, but all currently queued received data is consumed. afs_extract_data() does this, but the -EAGAIN return is switched to 0 inadvertantly Fix callback service message parsers to pass through -EAGAIN", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72378", "url": "https://ubuntu.com/security/CVE-2026-72378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix error code in afs_extract_vl_addrs() The error codes on these paths are only set on the first iteration through the loop. Set the correct error code on every iteration.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72389", "url": "https://ubuntu.com/security/CVE-2026-72389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: stp: Fix a potential use-after-free when deleting a bridge The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them. This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted. Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted. [1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64540", "url": "https://ubuntu.com/security/CVE-2026-64540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup() genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received. A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes. \tskb_put_data(gl_skb, packet->packet_data, size); then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up. BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72392", "url": "https://ubuntu.com/security/CVE-2026-72392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72396", "url": "https://ubuntu.com/security/CVE-2026-72396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: adm1275: Prevent reading uninitialized stack While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret < 0) { ... } for (mid = adm1275_id; mid->name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like \"adm12\", checking it against \"adm1275\" up to the length of \"adm1275\" will continue reading into uninitialized stack bounds. Prevent reading uninitialized memory by zeroing the stack array.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72400", "url": "https://ubuntu.com/security/CVE-2026-72400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: validate SRH length before reading fixed fields seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields. The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer. Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72406", "url": "https://ubuntu.com/security/CVE-2026-72406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sungem: fix probe error cleanup gem_init_one() calls gem_remove_one() when register_netdev() fails. gem_remove_one() unregisters and frees resources owned by the net_device, including the DMA block, MMIO mapping, PCI regions, and the net_device itself. gem_init_one() then falls through to its own cleanup labels and frees the same resources again. Keep the register_netdev() error path in gem_init_one(): clear drvdata so PM/remove paths do not see a half-registered device, remove the NAPI instance added during probe, and let the existing cleanup labels release the resources once. The issue was found by a local static-analysis checker for probe error paths. The reported path was manually inspected before sending this fix. Compile-tested with CONFIG_SUNGEM=y. Runtime testing was not performed because no sungem hardware is available.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72409", "url": "https://ubuntu.com/security/CVE-2026-72409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvneta: re-enable percpu interrupt on resume On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules NAPI poll, which calls enable_percpu_irq() on completion to unmask. If suspend occurs while NAPI poll is pending (between disable_percpu_irq in the ISR and enable_percpu_irq in poll completion), the interrupt is never re-enabled: 1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule() => MPIC masked, percpu_enabled cpumask bit cleared 2. NAPI poll does not complete before suspend proceeds (on PREEMPT_RT this is highly likely since softirqs run in ksoftirqd which gets frozen; on non-RT it can happen when softirq processing is deferred to ksoftirqd) 3. mvneta_stop_dev => napi_disable(): cancels the pending poll without executing the completion path 4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC (already masked, but records IRQS_SUSPENDED) 5. Resume: mpic_resume checks irq_percpu_is_enabled() => false (bit was cleared in step 1) => skips unmask 6. mvneta_start_dev only restores device-level INTR_NEW_MASK, does not touch the MPIC per-CPU mask Result: MPIC per-CPU interrupt stays masked permanently. The NIC generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never receives them, causing complete loss of network connectivity. Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path to unconditionally unmask the MPIC per-CPU interrupt regardless of pre-suspend state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72414", "url": "https://ubuntu.com/security/CVE-2026-72414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: round up PTP perout pin duration pin_duration is converted from the user-provided period to SJA1105 clock ticks and is later passed as the cycle_time argument to future_base_time(). Very small period values may become zero after the conversion, which can lead to a division by zero in future_base_time(). Round zero pin_duration up to 1 tick so that the smallest unsupported periods use the minimum non-zero hardware duration instead of passing zero to future_base_time().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64545", "url": "https://ubuntu.com/security/CVE-2026-64545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net, bpf: check master for NULL in xdp_master_redirect() xdp_master_redirect() dereferences the result of netdev_master_upper_dev_get_rcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency. The reach guard only checks netif_is_bond_slave(). On bond slave release bond_upper_dev_unlink() drops the upper-master adjacency before clearing IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window still passes netif_is_bond_slave() while master is already NULL, and faults on master->flags at offset 0xb0: BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdp_master_redirect (net/core/filter.c:4432) Call Trace: xdp_master_redirect (net/core/filter.c:4432) bpf_prog_run_generic_xdp (include/net/xdp.h:700) do_xdp_generic (net/core/dev.c:5608) __netif_receive_skb_one_core (net/core/dev.c:6204) process_backlog (net/core/dev.c:6319) __napi_poll (net/core/dev.c:7729) net_rx_action (net/core/dev.c:7792) handle_softirqs (kernel/softirq.c:622) __dev_queue_xmit (include/linux/bottom_half.h:33) packet_sendmsg (net/packet/af_packet.c:3082) __sys_sendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt The missing check dates back to the original code; commit 1921f91298d1 (\"net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master\") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72418", "url": "https://ubuntu.com/security/CVE-2026-72418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: prevent connlimit drops for early confirmed ct Commit 69894e5b4c5e (\"netfilter: nft_connlimit: update the count if add was skipped\") introduced a regression where packets for valid connections are dropped when using connlimit for soft-limiting scenarios. The issue occurs when a new connection reuses a socket currently in the TIME_WAIT state. In this scenario, the connection tracking entry is evaluated as already confirmed. Previously, __nf_conncount_add() assumed that if a connection was confirmed and did not originate from the loopback interface, it should skip the addition and return -EEXIST. Skipping the addition triggers a garbage collection run that cleans up the TIME_WAIT connection. Consequently, the active connection count drops to 0, which xt_connlimit mishandles, leading to the false rejection of the perfectly valid new connection. Fix this by replacing the interface check with protocol-agnostic state checks. We now skip the tree insertion and preserve the lockless garbage collection optimization only if the connection is IPS_ASSURED. This allows early-confirmed setup packets (such as reused TIME_WAIT sockets or locally generated SYN-ACKs) to be properly evaluated and counted without falsely dropping. The goto check_connections path is maintained to ensure these setup packets are deduplicated correctly. This has been tested with slowhttptest and HTTP server configured locally to ensure we are not breaking soft-limiting scenarios for local or external connections. In addition, it was tested with a OVS zone limit too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72421", "url": "https://ubuntu.com/security/CVE-2026-72421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't ignore error route in local/main tables. When CONFIG_IP_MULTIPLE_TABLES is enabled but no rule is added, fib_lookup() performs route lookup directly on two tables. Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table: # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache Once a random rule is added, the error route is respected: # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host Let's fix the inconsistent behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64538", "url": "https://ubuntu.com/security/CVE-2026-64538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix null-ptr-deref in fib6_nh_mtu_change(). fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown() clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(), but this re-fetch is unguarded; nexthop-backed routes survive addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is nulled. Return 0 when idev is NULL, matching rt6_mtu_change_route() and the fib6_mtu() fix in commit 5ad509c1fdad (\"ipv6: Fix null-ptr-deref in fib6_mtu().\"). Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6_nh_mtu_change+0x203/0x990 rt6_mtu_change_route+0x141/0x1d0 __fib6_clean_all+0xd0/0x160 rt6_mtu_change+0xb4/0x100 ndisc_router_discovery+0x24b5/0x2cb0 icmpv6_rcv+0x12e9/0x1710 ipv6_rcv+0x39b/0x410", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64546", "url": "https://ubuntu.com/security/CVE-2026-64546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72428", "url": "https://ubuntu.com/security/CVE-2026-72428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack slot index in nospec checks check_stack_write_fixed_off() computes the byte slot for a fixed-offset stack write as -off - 1, and records each written byte in slot_type[] with (slot - i) % BPF_REG_SIZE. The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a 4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates bytes 7..4. That can leave the second half-slot write without nospec_result even though the bytes being overwritten still require sanitization. Use the same slot index in the sanitization pre-check that the write path uses when updating slot_type[].", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72433", "url": "https://ubuntu.com/security/CVE-2026-72433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak This needs to test for nonzero retval.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72435", "url": "https://ubuntu.com/security/CVE-2026-72435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer() Sashiko pointed out that kfree_rcu() was called before rcu_assign_pointer() in handling the comment extension. Fix the order so that rcu_assign_pointer() called first.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72441", "url": "https://ubuntu.com/security/CVE-2026-72441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: fix kernel-infoleak in dgram_recvmsg() KMSAN reported a kernel-infoleak in move_addr_to_user(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925 ... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739 The issue occurs because the `pan_id` field of `struct ieee802154_addr` is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`. The execution flow is as follows: 1. `__ieee802154_rx_handle_packet()` declares a local `struct ieee802154_hdr hdr` on the stack. 2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse the source and destination addresses into this structure. 3. If the address mode is `IEEE802154_ADDR_NONE`, `ieee802154_hdr_get_addr()` previously only set the `mode` field, leaving the `pan_id` field containing uninitialized stack memory. 4. This uninitialized `pan_id` is later copied into a `struct sockaddr_ieee802154` in `dgram_recvmsg()` via `ieee802154_addr_to_sa()`. 5. Finally, `move_addr_to_user()` copies the socket address structure to user space, leaking the uninitialized bytes. Fix this by using `memset` to zero out the address structure in `ieee802154_hdr_get_addr()` when the mode is `IEEE802154_ADDR_NONE`.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72447", "url": "https://ubuntu.com/security/CVE-2026-72447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: hold socket lock when dumping endpoints in sctp_diag SCTP_DIAG endpoint dumping was traversing endpoint address lists without holding lock_sock(), while those lists could change concurrently via socket operations (e.g., bindx changes). This creates a race where nla_reserve() counts addresses under RCU protection, but the subsequent copy may see fewer entries, potentially leaking uninitialized memory to userspace. Fix this by: - Taking a reference on each endpoint during hash traversal - Moving socket operations (lock_sock()) outside read_lock_bh() - Serializing address list access during dump - Reworking sctp_for_each_endpoint() to support restart-based traversal with (net, pos) tracking Also: - Add WARN_ON_ONCE() for inconsistent address counts - Fix idiag_states filtering for LISTEN vs association cases - Skip dumping endpoints being freed (ep->base.dead) - Move dump position tracking into iterator, removing cb->args[4] and its comment for sctp_ep_dump()., - Update the comment for cb->args[4] and remove the comment for unused cb->args[5] for sctp_sock_dump(). Note: traversal is restart-based and may re-scan buckets multiple times, but this is acceptable due to small bucket sizes and required to support sleeping-safe callbacks. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64553", "url": "https://ubuntu.com/security/CVE-2026-64553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: psample: fix info leak in PSAMPLE_ATTR_DATA psample open codes nla_put() presumably to avoid wiping the data with 0s just to override it with packet data. This open coding is missing clearing the pad, however, each netlink attr is padded to 4B and data_len may not be divisible by 4B.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72448", "url": "https://ubuntu.com/security/CVE-2026-72448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix leak of SQ timestamp buffer on teardown The send-queue timestamp ring is allocated with qmem_alloc() when timestamping is used, but otx2_free_sq_res() never freed sq->timestamps, leaking that memory across ifdown and device removal. Add the missing qmem_free() alongside the other SQ companion buffers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72450", "url": "https://ubuntu.com/security/CVE-2026-72450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate selector family and prefixlen during match syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72459", "url": "https://ubuntu.com/security/CVE-2026-72459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: aa_label_alloc use aa_label_free on alloc failure aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init(). Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72460", "url": "https://ubuntu.com/security/CVE-2026-72460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72476", "url": "https://ubuntu.com/security/CVE-2026-72476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix possible use after free In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72479", "url": "https://ubuntu.com/security/CVE-2026-72479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: mma8452: handle I2C read error(s) in mma8452_read() Currently, If i2c_smbus_read_i2c_block_data() fails but mma8452_set_runtime_pm_state() succeeds, mma8452_read() returns 0. As a result, the caller mma8452_read_raw() assumes the read was successful and proceeds to use a buffer containing uninitialized stack memory. Add proper checking of the I2C read return value and propagate errors to the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72481", "url": "https://ubuntu.com/security/CVE-2026-72481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: ak8975: fix potential kernel stack memory leak Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72483", "url": "https://ubuntu.com/security/CVE-2026-72483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72484", "url": "https://ubuntu.com/security/CVE-2026-72484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: video: avoid double free on video register failure comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72489", "url": "https://ubuntu.com/security/CVE-2026-72489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: nvec: fix use-after-free in nvec_rx_completed() In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72492", "url": "https://ubuntu.com/security/CVE-2026-72492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in same_client_has_lease() same_client_has_lease() returns an opinfo pointer from ci->m_op_list after dropping ci->m_lock without taking a reference. smb_grant_oplock() then dereferences that pointer in copy_lease() and when checking breaking_cnt. A concurrent close can remove the old lease from ci->m_op_list and drop the last reference before the caller uses the returned pointer, leading to a use-after-free. Take a reference when same_client_has_lease() selects an existing lease, drop any previous match while scanning, and release the returned reference in smb_grant_oplock() after copying the lease state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72502", "url": "https://ubuntu.com/security/CVE-2026-72502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF) When MTU is large, ip6_default_advmss() can return IPV6_MAXPLEN (65535). This is interpreted by TCP as mss_clamp, allowing the MSS to reach 65535. However, 0xFFFF is also used as a magic value GSO_BY_FRAGS in the kernel. If a TCP packet with gso_size=0xFFFF is passed to skb_segment(), it will be mistakenly treated as GSO_BY_FRAGS, leading to a NULL pointer dereference because local TCP packets do not use frag_list. Fix this by returning min(IPV6_MAXPLEN, GSO_BY_FRAGS - 1) (65534) from ip6_default_advmss() when MTU is large. Also update the stale comment in ip6_default_advmss() which suggested that IPV6_MAXPLEN is returned to mean \"any MSS\".", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74256", "url": "https://ubuntu.com/security/CVE-2026-74256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check start and len are u32, so \tu64 last = start + len; evaluates start + len in 32-bit and wraps before storing it in last. The bounds check \tif (start >= offset + l || last > msg->sg.size) \t\treturn -EINVAL; can then be passed with an out-of-range start/len, after which the pop loop runs off the end of the scatterlist and sk_msg_shift_left() calls put_page() on the empty msg->sg.end slot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:sk_msg_shift_left net/core/filter.c:2957 [inline] RIP: 0010:____bpf_msg_pop_data net/core/filter.c:3103 [inline] RIP: 0010:bpf_msg_pop_data+0x753/0x1a10 net/core/filter.c:2984 Call Trace: bpf_prog_4cc92c278f4d5d56+0x1b1/0x1e8 bpf_prog_run_pin_on_cpu+0x107/0x320 include/linux/filter.h:746 sk_psock_msg_verdict+0x357/0x7f0 net/core/skmsg.c:934 tcp_bpf_send_verdict net/ipv4/tcp_bpf.c:420 [inline] tcp_bpf_sendmsg+0x766/0x1ae0 net/ipv4/tcp_bpf.c:583 __sock_sendmsg+0x153/0x1c0 net/socket.c:802 __sys_sendto+0x326/0x430 net/socket.c:2265 __x64_sys_sendto+0xe3/0x100 net/socket.c:2268 do_syscall_64+0x14c/0x480 entry_SYSCALL_64_after_hwframe+0x77/0x7f Widen the addition with a (u64) cast so the bound is evaluated in 64-bit and a len near U32_MAX no longer wraps below msg->sg.size. While here, change pop from int to u32. It counts bytes against the unsigned scatterlist lengths and can never be negative, so the signed type only invites sign-confusion in the pop loop.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64548", "url": "https://ubuntu.com/security/CVE-2026-64548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data() When the scatterlist ring is full or nearly full, bpf_msg_push_data() enters a copy fallback path and computes copy + len for the page allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING and both are u32, a crafted len can wrap the sum to a small value, causing an undersized allocation followed by an out-of-bounds memcpy. BUG: unable to handle page fault for address: ffffed104089a402 Oops: Oops: 0000 [#1] SMP KASAN NOPTI Call Trace: __asan_memcpy (mm/kasan/shadow.c:105) bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) bpf_prog_9ed8b5711920a7d7+0x2e/0x36 sk_psock_msg_verdict (net/core/skmsg.c:934) tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) __sys_sendto (net/socket.c:2206) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add an overflow check before the allocation.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74262", "url": "https://ubuntu.com/security/CVE-2026-74262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcm: use WRITE_ONCE() when changing lower socket callbacks kcm_attach() replaces a live lower TCP socket's sk_data_ready and sk_write_space callbacks with KCM handlers, and kcm_unattach() restores them later. Those callback-pointer updates are still plain stores even though the same fields can be read and invoked concurrently on other CPUs. If another CPU observes an older callback snapshot after the live field has already been restored, callback execution can run with a mismatched target and sk_user_data state, leading to stale or misdirected wakeups. Use WRITE_ONCE() for the callback replacement and restore operations so these shared callback fields follow the same visibility contract already established by the earlier 4022 fixes.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74265", "url": "https://ubuntu.com/security/CVE-2026-74265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: initialize gdma queue id to INVALID_QUEUE_ID mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74276", "url": "https://ubuntu.com/security/CVE-2026-74276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: xilinx: use FIFO occupancy register to determine buffer size The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. When a SPI transaction wants to write the amount of the FIFO size or more bytes, the following happens, for example with 16 bytes FIFO size: The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and starts the SPI hardware and goes sleep. The hardware then shifts out 17 bytes (FIFO + shift register) and simultaneously reads bytes into the RX FIFO, but it only has 16 places, so it looses one byte. Then TX FIFO empty asserts, wakes the driver again, which has a fast path and reads 16 bytes from the RX FIFO, but before reading the last 17th byte (which is lost) it does this: \tsr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); \tif (!(sr & XSPI_SR_RX_EMPTY_MASK)) { \t\txilinx_spi_rx(xspi); \t\trx_words--; \t} It reads the status register and checks if the RX FIFO is not empty. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74279", "url": "https://ubuntu.com/security/CVE-2026-74279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: cavium/cpt - fix DMA cleanup using wrong loop index The sg_cleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74280", "url": "https://ubuntu.com/security/CVE-2026-74280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/octeontx - fix DMA cleanup using wrong loop index The sg_cleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74281", "url": "https://ubuntu.com/security/CVE-2026-74281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74282", "url": "https://ubuntu.com/security/CVE-2026-74282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: prevent snt_unacked underflow on CONN_ACK tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: \ttsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74283", "url": "https://ubuntu.com/security/CVE-2026-74283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74284", "url": "https://ubuntu.com/security/CVE-2026-74284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: Don't make class passive twice update_vf() is called from two places for the same class during a single dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last packets while dequeuing: 1. The child calls qdisc_tree_reduce_backlog(), which, now that the child is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns the class passive (cl_nactive is decremented up the hierarchy). 2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time) to charge the dequeued bytes. On the second call the class is already passive, but its child qdisc is still empty, so update_vf() arms go_passive again: if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1; The leaf is then skipped by the cl_nactive == 0 check inside the loop, which does not clear go_passive, so the stale go_passive propagates to the parent and decrements its cl_nactive a second time. A parent that still has other active children is driven to cl_nactive == 0 and removed from the vttree, even though those siblings are still backlogged. They are never dequeued again and the qdisc stalls. Fix this by only arming go_passive when the class is actually active, so an already-passive class no longer triggers a second passive transition. The byte accounting (cl->cl_total += len) still runs for every ancestor, so dequeued bytes continue to be counted exactly once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64537", "url": "https://ubuntu.com/security/CVE-2026-64537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: reject invalid CCM interval at configuration time ccm_tx_work_expired() re-arms itself via queue_delayed_work() using the configured exp_interval converted by interval_to_us(). When exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range, interval_to_us() returns 0, causing the worker to fire immediately in a tight loop that allocates skbs until OOM. Fix this by validating exp_interval at configuration time: - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the netlink policy so userspace cannot set an invalid value. - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not yet been configured (defaults to 0 from kzalloc).", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74288", "url": "https://ubuntu.com/security/CVE-2026-74288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fib_rules: Don't dump dying fib_rule in fib_rules_dump(). rocker_router_fib_event() calls fib_rule_get() during RCU dump. If the fib_rule is dying, refcount_inc() will complain about it. Let's call refcount_inc_not_zero() in fib_rules_dump().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74292", "url": "https://ubuntu.com/security/CVE-2026-74292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tegra: tegra210_ahub: Validate written enum value tegra_ahub_put_value_enum() reads e->values[item[0]] before checking whether item[0] is within the enum item range. The existing check therefore happens too late to prevent an out-of-range read of the values array. Move the check before the array access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74293", "url": "https://ubuntu.com/security/CVE-2026-74293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: fsl_audmix: Validate written enum values fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src() convert the user-provided enum item with snd_soc_enum_item_to_val() before checking whether the item is within the enum's item count. The generic snd_soc_put_enum_double() helper performs that validation, but these callbacks use the converted value first: the clock-source path tests it with BIT(), and the output-source path indexes the prms transition table with it. Reject out-of-range enum items before converting them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74295", "url": "https://ubuntu.com/security/CVE-2026-74295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: hdac_hdmi: Validate written enum value hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range. An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74297", "url": "https://ubuntu.com/security/CVE-2026-74297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix undefined shift of user RQ WQE size set_rq_size() computes the RQ WQE size as \"1 << rq_wqe_shift\" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74305", "url": "https://ubuntu.com/security/CVE-2026-74305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tighten cgroup storage cookie checks for prog arrays The fix in commit abad3d0bad72 (\"bpf: Fix oob access in cgroup local storage\") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74312", "url": "https://ubuntu.com/security/CVE-2026-74312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: validate virtqueue index in mmap and fault paths vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74313", "url": "https://ubuntu.com/security/CVE-2026-74313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: hold vduse_lock across IDR lookup in open path vduse_dev_open() looks up struct vduse_dev through the IDR and then acquires dev->lock only after vduse_lock has been dropped. This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the same object from the IDR and free it before the open path locks the device, leading to a use-after-free. Close this race by keeping vduse_lock held until dev->lock has been acquired in the open path, matching the lock ordering already used by the destroy path.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74320", "url": "https://ubuntu.com/security/CVE-2026-74320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, \"mode\", &len) is just written over either the static \"640x480-16@60\" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74321", "url": "https://ubuntu.com/security/CVE-2026-74321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 (\"btrfs: refactor __btrfs_run_delayed_refs loop\") but were unintentionally lost afterwards.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74327", "url": "https://ubuntu.com/security/CVE-2026-74327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmalloc: fix NULL pointer dereference in is_vm_area_hugepages() find_vm_area() can return NULL if the given address is not a valid vmalloc area. Check the return value before dereferencing it to avoid a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74329", "url": "https://ubuntu.com/security/CVE-2026-74329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: unregister PM notifier on watchdog unregister watchdog_register_device() registers wdd->pm_nb when WDOG_NO_PING_ON_SUSPEND is set, but watchdog_unregister_device() does not remove it. This leaves an embedded notifier block on the PM notifier chain after the watchdog device has been unregistered. A later suspend/resume notification can then call watchdog_pm_notifier() with a stale watchdog_device pointer, or at minimum after wdd->wd_data has been cleared by watchdog_dev_unregister(). Unregister the PM notifier before tearing down the watchdog device.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74330", "url": "https://ubuntu.com/security/CVE-2026-74330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: fix lockless traversals of ->s_children Having the parent directory locked protects entries from removal by another thread, but it does *not* protect cursors from being moved around by lseek() - or freed, for that matter.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74331", "url": "https://ubuntu.com/security/CVE-2026-74331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix recursive lock in device_cache_fw_images() A recursive locking deadlock can occur in the firmware loader's power management notification handler. During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock. For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread. The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock. Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74339", "url": "https://ubuntu.com/security/CVE-2026-74339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Clear variable event pointer on read snd_seq_read() copies a queued variable-length event header to userspace before expanding the payload. Queued variable-length events use SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first extension cell. The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the copy, but it leaves data.ext.ptr untouched. A userspace sequencer client can therefore write a direct variable event to itself and read back the extension-cell kernel address from the returned header. Clear the temporary header pointer before copy_to_user(). The original queued event remains unchanged and is still passed to snd_seq_expand_var_event(), so payload expansion keeps using the internal chain.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74340", "url": "https://ubuntu.com/security/CVE-2026-74340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74346", "url": "https://ubuntu.com/security/CVE-2026-74346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74348", "url": "https://ubuntu.com/security/CVE-2026-74348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: require a ref for locking_state debugfs open debug_lockres_open() copies inode->i_private into struct debug_lockres and debug_lockres_release() later drops that pointer with dlm_put(). That only works if open successfully pins the struct dlm_ctxt. Today open calls dlm_grab(dlm) but ignores its return value. Once the last domain unregister has removed the context from dlm_domains, dlm_grab() returns NULL, yet open still stores the raw pointer and returns success. The later release path is outside the debugfs removal barrier, so it can call dlm_put() after dlm_free_ctxt_mem() has freed the context. KASAN reports this as a slab-use-after-free in dlm_put() called from debug_lockres_release(). Fail the open when dlm_grab() cannot acquire the reference and unwind the seq_file private state before returning. That keeps locking_state from handing out a file descriptor whose release path does not own the dlm_ctxt. The buggy scenario involves two paths, with each column showing the order within that path: locking_state debugfs open: last domain unregister: 1. debug_lockres_open() reads 1. dlm_unregister_domain() calls inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() calls 2. shutdown removes the dlm_ctxt from dlm_grab(dlm) and gets NULL. dlm_domains. 3. open still stores the raw dlm 3. final teardown reaches pointer in dl->dl_ctxt and dlm_free_ctxt_mem() and frees it. returns success. 4. debug_lockres_release() later calls dlm_put(dl->dl_ctxt). Validation reproduced this kernel report: KASAN slab-use-after-free in dlm_put+0x82/0x200 RIP: 0033:0x7f4d349bc9e0 The buggy address belongs to the object at ffff888103a3c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 816 bytes inside of freed 2048-byte region [ffff888103a3c000, ffff888103a3c800) Write of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) dlm_put+0x82/0x200 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) kasan_check_range+0x105/0x1b0 (?:?) debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) dlm_put+0x9/0x200 (?:?) debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) full_proxy_release+0x67/0x90 (?:?) __fput+0x1df/0x4b0 (?:?) do_raw_spin_lock+0x10f/0x1b0 (?:?) fput_close_sync+0xd2/0x170 (?:?) __x64_sys_close+0x55/0x90 (?:?) do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87) irqentry_exit+0xac/0x6e0 (?:?) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Freed by task stack: kasan_save_stack+0x33/0x60 (?:?) kasan_save_track+0x14/0x30 (?:?) kasan_save_free_info+0x3b/0x60 (?:?) __kasan_slab_free+0x5f/0x80 (?:?) kfree+0x30f/0x580 (?:?) dlm_put+0x1ce/0x200 (?:?) dlm_unregister_domain+0xf6/0xb30 (?:?) o2cb_cluster_disconnect+0x6b/0x90 (?:?) ocfs2_cluster_disconnect+0x41/0x70 (?:?) ocfs2_dlm_shutdown+0x1c4/0x220 (?:?) ocfs2_dismount_volume+0x38a/0x550 (?:?) generic_shutdown_super+0xc3/0x220 (?:?) kill_block_super+0x29/0x60 (?:?) deactivate_locked_super+0x66/0xe0 (?:?) cleanup_mnt+0x13d/0x210 (?:?) task_work_run+0xfa/0x170 (?:?) exit_to_user_mode_loop+0xd6/0x430 (?:?) do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74349", "url": "https://ubuntu.com/security/CVE-2026-74349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject FITRIM ranges shorter than a cluster ocfs2_trim_mainbm() trims the global bitmap in cluster units, but its too-short range validation only checks sb->s_blocksize. On filesystems with a cluster size larger than the block size, a FITRIM range that is at least one block but shorter than one cluster is accepted and shifted down to len == 0. The later start + len - 1 and len -= ... arithmetic then underflows and can drive trimming past the requested range. Reject ranges shorter than s_clustersize instead. That preserves the existing -EINVAL behavior for requests that cannot discard even one allocation unit and keeps zero-cluster trims out of the group walk.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74351", "url": "https://ubuntu.com/security/CVE-2026-74351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74359", "url": "https://ubuntu.com/security/CVE-2026-74359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs_lookup(): don't leave ->s_dentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74363", "url": "https://ubuntu.com/security/CVE-2026-74363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs commit 4f375ade6aa9 (\"bpf: Avoid RCU context warning when unpinning htab with internal structs\") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.). This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime(). KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags) The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74379", "url": "https://ubuntu.com/security/CVE-2026-74379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax/kmem: account for partial discontiguous resource upon removal When dev_dax_kmem_probe() partially succeeds (at least one range is mapped) but a subsequent range fails request_mem_region() or add_memory_driver_managed(), the probe silently continues, ultimately returning success, but with the corresponding range resource NULL'ed out. dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the underlying resource exists. When remove_memory() is called later, it returns 0 because the memory was never added which causes dev_dax_kmem_remove() to incorrectly assume the (nonexistent) resource can be removed and attempts cleanup on a NULL pointer. Fix this by skipping these ranges altogether, noting that these cases are considered success, such that the cleanup is still reached when all actually-added ranges are successfully removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74382", "url": "https://ubuntu.com/security/CVE-2026-74382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74390", "url": "https://ubuntu.com/security/CVE-2026-74390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr->pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don't overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74395", "url": "https://ubuntu.com/security/CVE-2026-74395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list before initializing the fields used by the shared error path. If eventfd_ctx_fdget() then fails, the unwind path dereferences event_sub->ev_file in uverbs_uobject_put() and calls subscribe_event_xa_dealloc() with an unset xa_key_level1. subscribe_event_xa_alloc() creates the XA entry exactly once for a given key_level1, on the first occurrence of that key. The unwind path must therefore call subscribe_event_xa_dealloc() exactly once for it as well. Enforce that by adding devx_key_in_sub_list() and calling subscribe_event_xa_dealloc() only when the last matching pending entry is being cleaned up.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74399", "url": "https://ubuntu.com/security/CVE-2026-74399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64544", "url": "https://ubuntu.com/security/CVE-2026-64544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents pefile_digest_pe_contents() computes the trailing-data hash length as pelen - (hashed_bytes + certs_size). A crafted PE can make the addition exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB. This is passed to crypto_shash_update() which reads out of bounds and panics on unmapped vmalloc guard pages. BUG: unable to handle page fault for address: ffffc900038d8000 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152) Call Trace: __sha256_update (lib/crypto/sha256.c:208) crypto_sha256_update (crypto/sha256.c:142) verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436) kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151) __do_sys_kexec_file_load (kernel/kexec_file.c:406) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Validate that the addition does not overflow and the result does not exceed pelen before the subtraction. Return -ELIBBAD on failure.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74402", "url": "https://ubuntu.com/security/CVE-2026-74402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix blocking and non-blocking rng logic The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74408", "url": "https://ubuntu.com/security/CVE-2026-74408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: fix OOB access from firmware tx status queue ID ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74410", "url": "https://ubuntu.com/security/CVE-2026-74410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478), causing an out-of-bounds read from the pre-allocated DMA buffer when skb_put_data copies new_len bytes. The USB transport already validates this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the PCIe path does not. Add a check that new_len does not exceed the DMA buffer size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74416", "url": "https://ubuntu.com/security/CVE-2026-74416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix memory leak in radeon_ring_restore() on lock failure radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74424", "url": "https://ubuntu.com/security/CVE-2026-74424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix NULL pointer dereference for a console without vc_data fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data. Keep fb_display[i].mode set only while the console has a vc_data. Check vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74426", "url": "https://ubuntu.com/security/CVE-2026-74426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: fix NULL pointer dereference in afs_get_tree() afs_alloc_sbi() uses kzalloc for memory allocation. And, if ctx->dyn_root is not null, as->cell and as->volume are null. In trace_afs_get_tree() they are dereferenced. KASAN error message: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550 include/trace/events/afs.h:1365 Call Trace: trace_afs_get_tree include/trace/events/afs.h:1365 [inline] afs_get_tree+0x922/0x1350 fs/afs/super.c:599 vfs_get_tree+0x8e/0x300 fs/super.c:1572 do_new_mount fs/namespace.c:3011 [inline] path_mount+0x14a5/0x2220 fs/namespace.c:3341 do_mount fs/namespace.c:3354 [inline] __do_sys_mount fs/namespace.c:3562 [inline] __se_sys_mount fs/namespace.c:3539 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3539 do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74438", "url": "https://ubuntu.com/security/CVE-2026-74438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun4i-ss - Remove insecure and unused rng_alg Remove sun4i_ss_rng, as it is insecure and unused: - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing locking and has a buffer overflow. sun4i_ss_prng_generate() fails to fill the entire buffer with cryptographic random bytes, because it rounds the destination length down and also doesn't actually wait for the hardware to be ready before pulling bytes from it. - No user of this code is known. It's usable only theoretically via the \"rng\" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen and discovered by Atuin - Automated Vulnerability Discovery Engine There's no point in fixing all these vulnerabilities individually when this is unused code, so let's just remove it.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74578", "url": "https://ubuntu.com/security/CVE-2026-74578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_skcipher - force synchronous processing on trees without ctx->state The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx->iv directly into the skcipher request. After io_submit() the socket lock is dropped and the request is processed asynchronously, so a concurrent sendmsg(ALG_SET_IV) can overwrite ctx->iv and make the in-flight request run under an attacker-controlled IV. For CTR/stream modes this is IV/keystream reuse and lets an unprivileged user recover the plaintext of a concurrent operation. Snapshotting ctx->iv into per-request storage for the async path is not sufficient. For ciphers with statesize == 0 - which includes cbc and ctr - the MSG_MORE inter-chunk IV chaining is carried solely by the in-place req->iv writeback, which a snapshot redirects into per-request memory that af_alg_free_resources() releases on completion, silently producing wrong output. Writing the IV back from the completion callback instead is not possible either: that would require lock_sock() there, but the callback can run in softirq/atomic context, so it must not sleep. Make the operation synchronous instead, which removes both the IV race and any writeback race. This is equivalent to the upstream resolution, commit fcc77d33a34c (\"net: Remove support for AIO on sockets\"), which removed the AIO socket path across net/ entirely and so produces the same end state for this file. This patch deviates from that commit deliberately: rather than removing AIO socket support tree-wide, which would be far too invasive for stable, it removes only the AIO branch in crypto/algif_skcipher.c. io_submit() now completes synchronously; AF_ALG async is rarely used in practice. The -EIOCBQUEUED check in skcipher_recvmsg() is now dead but harmless, and is left alone to keep the fix minimal. Tested on 6.6.y: attacker IV injection dropped from 2296/200000 to 0/200000 after the change; MSG_MORE chunked CTR output bit-identical to single-shot.", "cve_priority": "medium", "cve_public_date": "2026-08-16 09:16:00 UTC" }, { "cve": "CVE-2026-64600", "url": "https://ubuntu.com/security/CVE-2026-64600", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.", "cve_priority": "medium", "cve_public_date": "2026-07-23 06:16:00 UTC" }, { "cve": "CVE-2026-64187", "url": "https://ubuntu.com/security/CVE-2026-64187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fail recovery on a committed log item with no regions If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367)", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64266", "url": "https://ubuntu.com/security/CVE-2026-64266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before returning from fuse_ref_folio() fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues. Fix this by locking the request in fuse_ref_folio() before returning.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64268", "url": "https://ubuntu.com/security/CVE-2026-64268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64269", "url": "https://ubuntu.com/security/CVE-2026-64269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64271", "url": "https://ubuntu.com/security/CVE-2026-64271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: touchwin - reset the packet index on every complete packet tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: \ttw->data[tw->idx++] = data; \tif (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { \t\t... \t\ttw->idx = 0; \t} The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64273", "url": "https://ubuntu.com/security/CVE-2026-64273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - bound the device-reported force-feedback effect index iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: \ti = data[1] & 0x7f; \tif (data[1] & 0x80) { \t\tif (!test_and_set_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) \t\t\t... \t} else if (test_and_clear_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) { \t\t... \t} The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate \"effect started/stopped\" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64274", "url": "https://ubuntu.com/security/CVE-2026-64274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: goodix - clamp the device-reported contact count goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer \tu8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: \tts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64275", "url": "https://ubuntu.com/security/CVE-2026-64275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: elan_i2c - prevent division by zero and arithmetic underflow The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64276", "url": "https://ubuntu.com/security/CVE-2026-64276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64277", "url": "https://ubuntu.com/security/CVE-2026-64277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64279", "url": "https://ubuntu.com/security/CVE-2026-64279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter deregistration race Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name).", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64604", "url": "https://ubuntu.com/security/CVE-2026-64604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f No functional change intended.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64296", "url": "https://ubuntu.com/security/CVE-2026-64296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: \tif (++order == 2) \t\tuniname = p_uniname->name; \telse \t\tuniname += EXFAT_FILE_NAME_LEN; \tlen = exfat_extract_uni_name(ep, entry_uniname); \tname_len += len; \tunichar = *(uniname+len); \t*(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba (\"exfat: check if filename entries exceeds max filename length\")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64298", "url": "https://ubuntu.com/security/CVE-2026-64298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: include MAY_WRITE in open permission mask for O_TRUNC POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64299", "url": "https://ubuntu.com/security/CVE-2026-64299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64303", "url": "https://ubuntu.com/security/CVE-2026-64303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64306", "url": "https://ubuntu.com/security/CVE-2026-64306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: drbg - Fix returning success on failure in CTR_DRBG drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64312", "url": "https://ubuntu.com/security/CVE-2026-64312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64313", "url": "https://ubuntu.com/security/CVE-2026-64313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ecc - Fix carry overflow in vli multiplication The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows. The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow. When commit 3c4b23901a0c (\"crypto: ecdh - Add ECDH software support\") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation. Add proper handling for this boundary by accounting for the carry from the lower addition.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64315", "url": "https://ubuntu.com/security/CVE-2026-64315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64316", "url": "https://ubuntu.com/security/CVE-2026-64316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64317", "url": "https://ubuntu.com/security/CVE-2026-64317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge \"SL\" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64318", "url": "https://ubuntu.com/security/CVE-2026-64318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: aix: bound the pp_count scan to the ppe array aix_partition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array: \tint numpps = be16_to_cpu(pvd->pp_count); \t... \tfor (i = 0; i < numpps; i += 1) { \t\tstruct ppe *p = pvd->ppe + i; \t\t... \t\tlp_ix = be16_to_cpu(p->lp_ix); pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk pp_count. pp_count is an unvalidated __be16 read straight from the descriptor, so a crafted AIX image with pp_count larger than 1016 drives the loop to read pvd->ppe[i] past the end of the allocation (up to 65535 entries, ~2 MB out of bounds). The partition scan runs without mounting anything, when a block device with a crafted AIX/IBM partition table appears (an attacker-supplied image attached with losetup -P, or a device auto-scanned by udev), via msdos_partition() -> aix_partition(). Clamp the scan to the number of entries the ppe[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64322", "url": "https://ubuntu.com/security/CVE-2026-64322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when \tsizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: \tfor (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) { \t\tstruct sparingEntry *entry = &st->mapEntry[i]; \t\t... entry->origLocation ... \t} in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64323", "url": "https://ubuntu.com/security/CVE-2026-64323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate VAT header length against the VAT inode size udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size: \tmap->s_type_specific.s_virtual.s_start_offset = \t\tle16_to_cpu(vat20->lengthHeader); \tmap->s_type_specific.s_virtual.s_num_entries = \t\t(sbi->s_vat_inode->i_size - \t\t\tmap->s_type_specific.s_virtual.s_start_offset) >> 2; lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the \"block > s_num_entries\" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads \t((__le32 *)(iinfo->i_data + s_start_offset))[block] so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read. Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64324", "url": "https://ubuntu.com/security/CVE-2026-64324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate free block extents against the partition length udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64330", "url": "https://ubuntu.com/security/CVE-2026-64330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64331", "url": "https://ubuntu.com/security/CVE-2026-64331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running `usbip attach` from the host would cause the guest to oops with the following backtrace: Call trace: vep_dequeue+0x1c/0xe4 (P) usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34 __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64332", "url": "https://ubuntu.com/security/CVE-2026-64332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ulpi: fix memory leak on registration failure The allocated device name is never freed on early ULPI device registration failures. Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64333", "url": "https://ubuntu.com/security/CVE-2026-64333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64334", "url": "https://ubuntu.com/security/CVE-2026-64334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix hard lockup on disconnect If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled. Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect. This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64335", "url": "https://ubuntu.com/security/CVE-2026-64335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix broken rx after throttle If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound). Clear the throttle flags and submit the urb if needed when opening the port.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64336", "url": "https://ubuntu.com/security/CVE-2026-64336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan_pda: fix information leak The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspan_pda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer. Fix the information leak by making sure that keyspan_pda_write_start() returns zero on success as intended.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64337", "url": "https://ubuntu.com/security/CVE-2026-64337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: unmap request DMA on queue failure mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails. Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64338", "url": "https://ubuntu.com/security/CVE-2026-64338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: misc: uss720: unregister parport on probe failure uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered. Leaving the port registered is more than a private allocation leak: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is about to release. Undo the pre-announce registration in the get_1284_register() failure branch before jumping to the common private-data cleanup path. Clear priv->pp first, matching the disconnect path and avoiding a stale pointer in the private data. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64340", "url": "https://ubuntu.com/security/CVE-2026-64340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: legousbtower: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64342", "url": "https://ubuntu.com/security/CVE-2026-64342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: iowarrior: fix use-after-free on disconnect Submitted write URBs are not stopped on close() and therefore need to be stopped unconditionally on disconnect() to avoid use-after-free in the completion handler.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64343", "url": "https://ubuntu.com/security/CVE-2026-64343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ldusb: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64344", "url": "https://ubuntu.com/security/CVE-2026-64344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64346", "url": "https://ubuntu.com/security/CVE-2026-64346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: Fix use-after-free in gadget_match_driver The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usb_del_gadget() frees the udc memory (e.g., via mode-switch work) while gadget_match_driver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed: [39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr : gadget_match_driver+0x34/0x60 ... [39430.911890][ T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][ T1171] Workqueue: events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usb_gadget_release() routine to the core. When the gadget is added, usb_add_gadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usb_gadget_release() drops the reference to the udc and then calls the gadget's release routine.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64347", "url": "https://ubuntu.com/security/CVE-2026-64347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler The OTG branch of composite_setup() falls back to the first configuration when none is selected: \tif (cdev->config) \t\tconfig = cdev->config; \telse \t\tconfig = list_first_entry(&cdev->configs, \t\t\t\t\t struct usb_configuration, list); \tif (!config) \t\tgoto done; \t... \tmemcpy(req->buf, config->descriptors[0], value); list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the \"if (!config)\" check is dead. When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer. cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch. Use list_first_entry_or_null() so the existing check does its job.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64350", "url": "https://ubuntu.com/security/CVE-2026-64350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info() cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and stream_rings array, but leaves stream_ctx_array allocated. Free the stream context array before falling through to the stream_rings cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64351", "url": "https://ubuntu.com/security/CVE-2026-64351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: bound RX frame length in kalmia_rx_fixup() kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usb_packet_length to about 65530. That bypasses the usb_packet_length < ether_packet_length truncation path. The device-supplied ether_packet_length, a le16 up to 65535 read from header_start[2], then drives a memcmp() and the following skb_trim() and skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10, which is 14000 bytes. That is an out of bounds read. Require both the start and end framing headers to be present before subtracting them, on every loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64359", "url": "https://ubuntu.com/security/CVE-2026-64359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64360", "url": "https://ubuntu.com/security/CVE-2026-64360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64362", "url": "https://ubuntu.com/security/CVE-2026-64362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: lg-g15: cancel pending work on remove to fix a use-after-free lg_g15_data is allocated with devm and holds a work item. The report handlers schedule that work straight from device input. lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key, and lg_g510_leds_event() does it too. The worker dereferences the lg_g15_data back through container_of. The driver had no remove callback and never cancelled the work. So if a report scheduled the work and the keyboard was then unplugged, devres freed lg_g15_data while the work was still pending or running, and the worker touched freed memory. This is a use-after-free. It is reachable as a race on device unplug. Add a remove callback that cancels the work before devres frees the state. g15->work is only initialized for the models that schedule it (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the cancel on g15->work.func to avoid cancelling a work that was never set up. The g15 NULL test mirrors the one already in lg_g15_raw_event().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68091", "url": "https://ubuntu.com/security/CVE-2026-68091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: stop hardware after post-start probe failures wacom_parse_and_register() starts HID hardware before registering inputs and initializing pad LEDs/remotes. Those later steps can fail, but their error paths currently release Wacom resources without stopping the HID hardware. Route post-hid_hw_start() failures through hid_hw_stop() before releasing driver resources. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64370", "url": "https://ubuntu.com/security/CVE-2026-64370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference via get_pid() and stores it in timer.it.cpu.pid. If the subsequent posix_cpu_timer_set() call fails, the function returns immediately without calling posix_cpu_timer_del() to release the pid reference, causing a leak. Fix it by calling posix_cpu_timer_del() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64372", "url": "https://ubuntu.com/security/CVE-2026-64372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: pcc: fix use-after-free and double free in _OSC evaluation pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the two-phase _OSC negotiation. Between the two calls it freed output.pointer but left output.length unchanged. Since acpi_evaluate_object() treats a non-zero length with a non-NULL pointer as an existing buffer to write into, the second call wrote into freed memory (use-after-free). The subsequent kfree(output.pointer) at out_free then freed the same pointer a second time (double free). Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first result, so ACPICA allocates a fresh buffer for each phase independently.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64373", "url": "https://ubuntu.com/security/CVE-2026-64373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path. Unlike the normal system suspend path, the reboot path does not call freeze_processes(), so userspace processes and kernel threads remain active. This allows CPU hotplug operations to run concurrently with cpufreq_suspend(). The original code has no synchronization with CPU hotplug, leading to a race condition where governor_data can be freed by the hotplug path while cpufreq_suspend() is still accessing it, resulting in a null pointer dereference: Unable to handle kernel NULL pointer dereference Call Trace: do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200 Fix this by adding cpus_read_lock()/cpus_read_unlock() to cpufreq_suspend() to block CPU hotplug operations while suspend is in progress. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64374", "url": "https://ubuntu.com/security/CVE-2026-64374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64403", "url": "https://ubuntu.com/security/CVE-2026-64403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64408", "url": "https://ubuntu.com/security/CVE-2026-64408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: pin L2CAP connection during netdev registration bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64411", "url": "https://ubuntu.com/security/CVE-2026-64411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: terminate table name before find_table_lock() update_counters() and compat_update_counters() forward a user-supplied 32-byte table name to find_table_lock() without NUL-terminating it. On a lookup miss, find_inlist_lock() calls try_then_request_module(..., \"%s%s\", \"ebtable_\", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte. BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) __request_module (kernel/module/kmod.c:150) do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) update_counters (net/bridge/netfilter/ebtables.c:1440) do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573) nf_setsockopt (net/netfilter/nf_sockopt.c:101) ip_setsockopt (net/ipv4/ip_sockglue.c:1424) raw_setsockopt (net/ipv4/raw.c:847) __sys_setsockopt (net/socket.c:2393) ... compat_do_replace() shares the same unterminated name via compat_copy_ebt_replace_from_user(); terminate it there too so all find_table_lock() callers behave alike. The other callers already terminate the name after the copy.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64412", "url": "https://ubuntu.com/security/CVE-2026-64412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: module names must be null-terminated We need to explicitly check the length, else we may pass non-null terminated string to request_module().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64420", "url": "https://ubuntu.com/security/CVE-2026-64420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: cros_ec: Delay dev_set_drvdata() until probe success If ec_device_probe() fails, cros_ec_class_release releases memory for the cros_ec_dev structure. However, because the drvdata was already set, sub-drivers like cros_ec_typec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when cros_ec_typec attempts to access &typec->ec->ec->dev on a device that has already been released. Move dev_set_drvdata() to ensure that the pointer is only made available once all initialization steps have succeeded. sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' Call trace: sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... BUG: KASAN: invalid-access in __memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOT_MODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: events_unbound deferred_probe_work_func Call trace: __memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64422", "url": "https://ubuntu.com/security/CVE-2026-64422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP socket state. The sysctl is stored as an `int` but copied into the `u32` `tp->reordering` field for new sockets, so negative writes wrap to large values. With `tcp_mtu_probing=2`, the wrapped value can overflow the `tcp_mtu_probe()` size calculation and drive the MTU probing path into an out-of-bounds read. Route `tcp_reordering` writes through `proc_dointvec_minmax()` and require it to be at least 1. Also require `tcp_max_reordering` to be at least 1 so the configured maximum cannot become negative either. When registering the table for a non-init network namespace, relocate `extra2` pointers that refer into `init_net.ipv4` so the `tcp_reordering` upper bound follows that namespace's `tcp_max_reordering`. Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`. This keeps the send queue and window checks from being bypassed through signed integer overflow.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64423", "url": "https://ubuntu.com/security/CVE-2026-64423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: remove multicast group from hash table on device destruction When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through the multicast list and calls ip_ma_put() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mc_hash). Since the device remains published in dev->ip_ptr until after ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs. Fix this by unlinking the multicast group from mc_hash using ip_mc_hash_remove() before scheduling it for reclamation. BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276 Call Trace: dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 Allocated by task 2239: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40 __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300 Freed by task 0: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50 __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64425", "url": "https://ubuntu.com/security/CVE-2026-64425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 10dc95939817 (\"io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64429", "url": "https://ubuntu.com/security/CVE-2026-64429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: eic-sprd: use raw_spinlock_t in the irq startup path sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64430", "url": "https://ubuntu.com/security/CVE-2026-64430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid calling pci_irq_vector() from hardirq context ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive the vector number. pci_irq_vector() calls msi_get_virq() that takes a mutex and can therefore trigger \"scheduling while atomic\" splats: BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedule_preempt_disabled+0x28/0x50 __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf] __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64432", "url": "https://ubuntu.com/security/CVE-2026-64432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns In the analysis pass of $LogFile journal replay, log_replay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcns_follow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time: BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array: 1. dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow. 2. lrh->target_vcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge size_t. Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL. This mirrors the bounds-check pattern added in commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") and commit 0ca0485e4b2e (\"fs/ntfs3: validate rec->used in journal-replay file record check\").", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68090", "url": "https://ubuntu.com/security/CVE-2026-68090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) \treturn; obj = alloc(); \t\t\t\tif (!obj) { \t\t\t\t\t\t\t// Out of memory \tdebug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized \tif (!IS_ERR_OR_NULL(obj)) \treturn; if (!obj) { \tdebug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64435", "url": "https://ubuntu.com/security/CVE-2026-64435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: Fix data races of skb_queue_len() readers on audit_queue Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races. All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn() KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 value changed: 0x00000001 -> 0x00000000 ================================================================== Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side. [PM: line length tweak]", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64436", "url": "https://ubuntu.com/security/CVE-2026-64436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: initialize alg_key_len for IPComp states pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name: \tx->calg = kmalloc_obj(*x->calg); \tif (!x->calg) { \t\terr = -ENOMEM; \t\tgoto out; \t} \tstrcpy(x->calg->alg_name, a->name); \tx->props.calgo = sa->sadb_sa_encrypt; Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data. calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE: \txfrm_state_migrate() \t xfrm_state_clone_and_setup() \t x->calg = xfrm_algo_clone(orig->calg); \t kmemdup(orig, xfrm_alg_len(orig)); where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0): BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90 ___sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4) Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail. The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent. Initialize calg->alg_key_len to 0, matching the aalg/ealg branches.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64599", "url": "https://ubuntu.com/security/CVE-2026-64599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: amlogic - avoid double cleanup in meson_crypto_probe() When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker(). Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM. ================================================================== BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0 Read of size 8 at addr ff1100010c057a68 by task insmod/265 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? kthread_destroy_worker+0xb2/0xd0 ? kthread_destroy_worker+0xb2/0xd0 kasan_report+0xca/0x100 ? kthread_destroy_worker+0xb2/0xd0 kthread_destroy_worker+0xb2/0xd0 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto] platform_probe+0x99/0x140 really_probe+0x1c6/0x6a0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x248/0x310 ? acpi_driver_match_device+0xb0/0x100 driver_probe_device+0x48/0x210 ? __pfx___device_attach_driver+0x10/0x10 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x104/0x190 ? __pfx_bus_for_each_drv+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 __device_attach+0x19d/0x3b0 ? __pfx___device_attach+0x10/0x10 ? do_raw_spin_unlock+0x53/0x220 device_initial_probe+0x78/0xa0 bus_probe_device+0x5b/0x130 device_add+0xcfd/0x1430 ? __pfx_device_add+0x10/0x10 ? insert_resource+0x34/0x50 ? lock_release+0xc9/0x290 platform_device_add+0x24e/0x590 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro] meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro] do_one_initcall+0xc0/0x450 ? __pfx_do_one_initcall+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 ? __create_object+0x59/0x80 ? kasan_unpoison+0x27/0x60 do_init_module+0x27b/0x7d0 ? __pfx_do_init_module+0x10/0x10 ? kasan_quarantine_put+0x84/0x1d0 ? kfree+0x32c/0x510 ? load_module+0x561e/0x5ff0 load_module+0x54fe/0x5ff0 ? __pfx_load_module+0x10/0x10 ? security_file_permission+0x20/0x40 ? kernel_read_file+0x23d/0x6e0 ? mmap_region+0x235/0x4a0 ? __pfx_kernel_read_file+0x10/0x10 ? __file_has_perm+0x2c0/0x3e0 init_module_from_file+0x158/0x180 ? __pfx_init_module_from_file+0x10/0x10 ? __lock_acquire+0x45a/0x1ba0 ? idempotent_init_module+0x315/0x610 ? lock_release+0xc9/0x290 ? lock ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64440", "url": "https://ubuntu.com/security/CVE-2026-64440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB write in HT_caps_handler() HT_caps_handler() iterates pIE->length bytes and writes into HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct HT_caps_element). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlme_ext_info. Truncate the iteration count to the size of HT_caps.u.HT_cap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HT_caps_enable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64536", "url": "https://ubuntu.com/security/CVE-2026-64536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop The loop in is_ap_in_tkip() iterates over IEs without verifying that enough bytes remain before dereferencing the IE header or its payload: - pIE->element_id and pIE->length are read without checking that i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the buffer causes an OOB read. - For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12, which requires pIE->length >= 16. For WLAN_EID_RSN it compares pIE->data + 8, requiring pIE->length >= 12. Neither requirement is checked. Add the missing IE header and payload bounds checks and guard each data access with an explicit pIE->length minimum, matching the pattern established in update_beacon_info().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-64442", "url": "https://ubuntu.com/security/CVE-2026-64442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64443", "url": "https://ubuntu.com/security/CVE-2026-64443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the element_id byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64444", "url": "https://ubuntu.com/security/CVE-2026-64444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i < pkt_len. When a malicious AP sends an AssocResponse whose last IE has only one byte remaining in the frame (the element_id byte lands at pkt_len-1), the loop reads pIE->length from pframe[pkt_len], which is one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pkt_len, silently passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pkt_len.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64445", "url": "https://ubuntu.com/security/CVE-2026-64445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth() OnAuth() has two bugs in the shared-key authentication path. When the Privacy bit is set, rtw_wep_decrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtw_wep_decrypt(), length is computed as: length = len - WLAN_HDR_A3_LEN - iv_len and then passed as (length - 4) to crc32_le(). If len is less than WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative and, after the implicit cast to size_t, causes crc32_le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path. When processing a seq=3 response, rtw_get_ie() stores the Challenge Text IE length in ie_len, but the subsequent memcmp() always reads 128 bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64450", "url": "https://ubuntu.com/security/CVE-2026-64450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it (\"if (glen > dlen) break;\"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: \tthis_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), \t\t\t GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: \"if (glen > dlen) break;\" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means \"legacy peer without Selective ACK\", a distinct legitimate state.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64452", "url": "https://ubuntu.com/security/CVE-2026-64452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix NHC entry use-after-free on error path lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding lowpan_nhc_lock. If the descriptor has no uncompress callback, the error path drops the lock before printing nhc->name. lowpan_nhc_del() removes descriptors under the same lock and then relies on synchronize_net() before the owning module can be unloaded. That only waits for net RX RCU readers. lowpan_header_decompress() is also exported and can be reached from callers that are not necessarily covered by the net core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive path. This leaves a race where one task drops lowpan_nhc_lock in the error path, another task unregisters and frees the matching descriptor after synchronize_net() returns, and the first task then dereferences nhc->name for the warning. With the post-unlock window widened, KASAN reports: BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220 Read of size 8 lowpan_nhc_do_uncompression lowpan_header_decompress Fix this by printing the warning before dropping lowpan_nhc_lock, so the descriptor name is read while unregister is still excluded. The malformed packet is still rejected with -ENOTSUPP.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64454", "url": "https://ubuntu.com/security/CVE-2026-64454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: run gadget disconnect from sleepable suspend context dwc3_gadget_suspend() takes dwc->lock with IRQs disabled and then calls dwc3_disconnect_gadget(). For async callbacks that helper only uses plain spin_unlock()/spin_lock(), so the gadget ->disconnect() callback still runs with IRQs disabled and any sleepable callback trips Lockdep. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the dwc3_gadget_suspend() -> dwc3_disconnect_gadget() -> gadget_driver->disconnect() chain, and Lockdep reported: BUG: sleeping function called from invalid context gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] Keep the disconnect callback selection in one common helper, but add a sleepable suspend-side wrapper which snapshots the callback under dwc->lock and then runs it after spin_unlock_irqrestore(). The regular event path still uses the existing spin_unlock()/spin_lock() window.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64455", "url": "https://ubuntu.com/security/CVE-2026-64455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: chaoskey: Fix slab-use-after-free in chaoskey_release() The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: \tBUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) \tRead of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 \tHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 \tCall Trace: \t \t dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) \t print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) \t kasan_report (mm/kasan/report.c:595) \t dev_driver_string (drivers/base/core.c:2406) \t __dynamic_dev_dbg (lib/dynamic_debug.c:906) \t chaoskey_release (drivers/usb/misc/chaoskey.c:323) \t __fput (fs/file_table.c:510) \t fput_close_sync (fs/file_table.c:615) \t __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) \t do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) \t entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64456", "url": "https://ubuntu.com/security/CVE-2026-64456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: virtio: clamp device-reported used.len at copy_data() random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64189", "url": "https://ubuntu.com/security/CVE-2026-64189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64465", "url": "https://ubuntu.com/security/CVE-2026-64465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix sleep in atomic context in xhci_free_streams() When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64468", "url": "https://ubuntu.com/security/CVE-2026-64468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_free_transaction() In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64469", "url": "https://ubuntu.com/security/CVE-2026-64469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_thread_release() When a thread exits, binder_thread_release() walks its transaction stack to clear the t->from and t->to_proc that correspond with the exiting thread. However, a process dying in parallel might attempt to kfree some of these transactions. And if one of them has no associated t->to_proc, the t->to_proc->inner_lock will not be acquired. This means that transaction accesses in binder_thread_release() after t->to_proc has been cleared might race with binder_free_transaction() and cause a use-after-free error as reported by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798 Write of size 8 at addr ffff000016627500 by task X/715 CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...] Allocated by task 717 on cpu 18 at 67.267803s: __kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+0x554/0x8150 binder_thread_write+0xa30/0x4354 binder_ioctl+0x20f0/0x299c [...] Freed by task 202 on cpu 18 at 90.416221s: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_free_transaction+0x150/0x294 binder_send_failed_reply+0x398/0x6d8 binder_release_work+0x3e4/0x4ec binder_deferred_func+0xbd8/0x104c [...] ================================================================== In order to avoid this, make sure that binder_free_transaction() reads the t->to_proc under the transaction lock. This will serialize the transaction release with the accesses in binder_thread_release(). Plus, it matches the documented locking rules for @to_proc.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64470", "url": "https://ubuntu.com/security/CVE-2026-64470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on marvell probe failure Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64471", "url": "https://ubuntu.com/security/CVE-2026-64471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on registration failure Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64478", "url": "https://ubuntu.com/security/CVE-2026-64478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64483", "url": "https://ubuntu.com/security/CVE-2026-64483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. \tcount = be32_to_cpu(payload->sample_count); \tif (likely(count <= (length - 16) / 4)) \t\tisight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64484", "url": "https://ubuntu.com/security/CVE-2026-64484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es1938: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. snd_es1938_mixer() does not check the return value before dereferencing the pointer, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64487", "url": "https://ubuntu.com/security/CVE-2026-64487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every iteration it advances buf and subtracts the block size while looping on \"while (len)\". len is urb->actual_length. That value is supplied by the device and is not guaranteed to be a multiple of 16. When a final short block leaves len between 1 and 15, the loop runs once more, reads up to buf[15], and then does \"len -= TKS4_MSGBLOCK_SIZE\". As len is unsigned this underflows to a huge value. The loop then keeps iterating and walking buf far past the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus block id happens to be hit. Iterate only while a full message block is available. This stops the unsigned underflow and silently drops any trailing partial block, which carries no complete control value anyway. The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1 and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor urb->actual_length before dispatching.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64494", "url": "https://ubuntu.com/security/CVE-2026-64494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: fix runtime PM leak on read error gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the \"out\" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a \"goto out\" to ensure the reference is properly dropped on the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64495", "url": "https://ubuntu.com/security/CVE-2026-64495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: bmg160: bail out when bandwidth/filter is not in table bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: \tfor (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { \t\tif (bmg160_samp_freq_table[i].bw_bits == bw_bits) \t\t\tbreak; \t} \t*val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64496", "url": "https://ubuntu.com/security/CVE-2026-64496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64497", "url": "https://ubuntu.com/security/CVE-2026-64497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64602", "url": "https://ubuntu.com/security/CVE-2026-64602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: spear: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in spear_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, spear_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ spear_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64500", "url": "https://ubuntu.com/security/CVE-2026-64500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: lpc32xx: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64503", "url": "https://ubuntu.com/security/CVE-2026-64503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64504", "url": "https://ubuntu.com/security/CVE-2026-64504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer \tu16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: \tcount = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: \tif (samples && count > samples) \t\tcount = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: \tbmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64505", "url": "https://ubuntu.com/security/CVE-2026-64505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check for header Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68088", "url": "https://ubuntu.com/security/CVE-2026-68088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check to response query Add variable representations for BufLength and BufOffset in rndis_query_response(), and perform a length check on them. This is identical to how rndis_set_response() handles these parameters.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-53392", "url": "https://ubuntu.com/security/CVE-2026-53392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53402", "url": "https://ubuntu.com/security/CVE-2026-53402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font() When fbcon_do_set_font() fails (e.g., due to a memory allocation failure inside vc_resize() under heavy memory pressure), it jumps to the `err_out` label to roll back the console state. However, the current rollback logic forgets to restore the `hi_font` state, leading to a severe state machine corruption. Earlier in the function, `set_vc_hi_font()` might be called to change `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()` subsequently fails, the `err_out` path restores `vc_font.charcount` but entirely skips rolling back the `vc_hi_font_mask` and the screen buffer. This mismatch leaves the terminal in a desynchronized state. Because `vc_hi_font_mask` remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure. Fix this by adding the missing rollback logic for the `hi_font` mask and screen buffer in the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63810", "url": "https://ubuntu.com/security/CVE-2026-63810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Avoid mounting the bdev pseudo-filesystem in userspace The bdev pseudo-filesystem is an internal kernel filesystem with which userspace should not interfere. Unregister it so that userspace cannot even attempt to mount it. This fixes a bug [1] that occurs when attempting to access files, because the system call move_mount() uses pointers declared in the inode_operations structure, which for the bdev pseudo-filesystem are always equal to 0. `inode->i_op = &empty_iops;` [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:0x0 Call Trace: lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460 open_last_lookups fs/namei.c:3550 [inline] path_openat+0x953/0x2700 fs/namei.c:3780 do_filp_open+0x1c5/0x410 fs/namei.c:3810 do_sys_openat2+0x171/0x4d0 fs/open.c:1318 do_sys_open fs/open.c:1334 [inline] __do_sys_openat fs/open.c:1350 [inline] __se_sys_openat fs/open.c:1345 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68459", "url": "https://ubuntu.com/security/CVE-2026-68459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs() When we mount device w/ gc_merge mount option, we may suffer below potential deadlock: Kworker\t\t\t\t\tGC trehad\t\t\tTruncator - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback --- set writeback flag on folio - f2fs_outplace_write_data : cached folio in internal bio cache - f2fs_balance_fs - wake_up(gc_thread) : wake up gc thread to run foreground GC - finish_wait(fggc_wq) : wait on the waitqueue --- wait on GC thread to finish the work \t\t\t\t\t\t\t\t\t- truncate_inode_pages_range \t\t\t\t\t\t\t\t\t - __filemap_get_folio(, FGP_LOCK) --- lock folio \t\t\t\t\t\t\t\t\t - truncate_inode_partial_folio \t\t\t\t\t\t\t\t\t - folio_wait_writeback --- wait on writeback being cleared \t\t\t\t\t- do_garbage_collect \t\t\t\t\t - move_data_page \t\t\t\t\t - f2fs_get_lock_data_folio \t\t\t\t\t - lock on folio --- blocked on folio's lock In order to avoid such deadlock, let's call below functions to commit cached bios in GC_MERGE path of f2fs_balance_fs() as the same as we did in NOGC_MERGE path. - f2fs_submit_merged_write(sbi, DATA); - f2fs_submit_all_merged_ipu_writes(sbi);", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-68460", "url": "https://ubuntu.com/security/CVE-2026-68460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in f2fs_balance_fs() When the f2fs filesystem space is nearly exhausted, we encounter deadlock issues as below: INFO: task A:1890 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:A state:D stack:0 pid:1890 tgid:1626 ppid:1153 flags:0x00000204 Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 folio_wait_bit+0x20/0x38 folio_wait_writeback+0x54/0xc8 truncate_inode_partial_folio+0x70/0x1e0 truncate_inode_pages_range+0x1b0/0x450 truncate_pagecache+0x54/0x88 f2fs_file_write_iter+0x3e8/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task kworker/u8:11:2680853 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:11 state:D stack:0 pid:2680853 tgid:2680853 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 __filemap_get_folio+0x214/0x348 pagecache_get_page+0x20/0x70 f2fs_get_read_data_page+0x150/0x3e8 f2fs_get_lock_data_page+0x2c/0x160 move_data_page+0x50/0x478 do_garbage_collect+0xd38/0x1528 f2fs_gc+0x240/0x7e0 f2fs_balance_fs+0x1a0/0x208 f2fs_write_single_data_page+0x6e4/0x730 f2fs_write_cache_pages+0x378/0x9b0 f2fs_write_data_pages+0x2e4/0x388 do_writepages+0x8c/0x2c8 __writeback_single_inode+0x4c/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x200 INFO: task kworker/u8:8:2641297 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:8 state:D stack:0 pid:2641297 tgid:2641297 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_write_inode+0xf4/0x328 __writeback_single_inode+0x370/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x20 INFO: task B:1902 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:B state:D stack:0 pid:1902 tgid:1626 ppid:1153 flags:0x0000020c Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_map_blocks+0x94c/0x1110 f2fs_file_write_iter+0x228/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task sync:2769849 blocked for more than 120 seconds. Tainted: G ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63815", "url": "https://ubuntu.com/security/CVE-2026-63815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: bound i_inline_xattr_size for non-inline-xattr inodes When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: \tif (f2fs_sb_has_flexible_inline_xattr(sbi)) \t\tfi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: \tMAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) \tNR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) \taddrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: \twhile (bit_pos < d->max)\t\t/* fs/f2fs/dir.c */ \t\t... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ... Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files. Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63818", "url": "https://ubuntu.com/security/CVE-2026-63818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate orphan inode entry count f2fs_recover_orphan_inodes() trusts the orphan block entry_count when replaying orphan inodes from the checkpoint pack. A corrupted entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the ino[] array and interpret footer or following data as inode numbers. On a crafted image, mounting an unpatched kernel can drive orphan recovery into f2fs_bug_on() and panic the kernel. Validate entry_count before consuming entries so corrupted checkpoint data fails the mount with -EFSCORRUPTED and requests fsck instead. Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be recorded in the superblock s_errors[] field. This gives fsck a persistent hint even though mount-time orphan recovery failure may leave no chance to persist SBI_NEED_FSCK through a checkpoint.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68461", "url": "https://ubuntu.com/security/CVE-2026-68461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device property: initialize the remaining fields of fwnode_handle in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitialized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. While at it: initialize the remaining fields of struct fwnode_handle too just to be sure. [ Fix typo in commit message. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63829", "url": "https://ubuntu.com/security/CVE-2026-63829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper. Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs. Commit 8b484efd5cb4 (\"ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\") added the same check on the ioctl path. This adds it on RTM_NEWLINK.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2022-3114", "url": "https://ubuntu.com/security/CVE-2022-3114", "cve_description": "An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference.", "cve_priority": "negligible", "cve_public_date": "2022-12-14 21:15:00 UTC" }, { "cve": "CVE-2026-64514", "url": "https://ubuntu.com/security/CVE-2026-64514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is \"is this fault still WP-blocked?\". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says \"wait\", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns \"don't wait\" and lets the fault path retry.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53399", "url": "https://ubuntu.com/security/CVE-2026-53399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: release layout stid on setlease failure nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "high", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-31451", "url": "https://ubuntu.com/security/CVE-2026-31451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption. The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-43355", "url": "https://ubuntu.com/security/CVE-2026-43355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: bh1780: fix PM runtime leak on error path Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53139", "url": "https://ubuntu.com/security/CVE-2026-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23364", "url": "https://ubuntu.com/security/CVE-2026-23364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Compare MACs in constant time To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-46208", "url": "https://ubuntu.com/security/CVE-2026-46208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2023-54271", "url": "https://ubuntu.com/security/CVE-2023-54271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init blk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This happens because iocg->ioc is NULL. The field is initialized by ioc_pd_init() and never cleared. The NULL deref is caused by blkcg_activate_policy() installing blkg_policy_data before initializing it. blkcg_activate_policy() was doing the following: 1. Allocate pd's for all existing blkg's and install them in blkg->pd[]. 2. Initialize all pd's. 3. Online all pd's. blkcg_activate_policy() only grabs the queue_lock and may release and re-acquire the lock as allocation may need to sleep. ioc_weight_write() grabs blkcg->lock and iterates all its blkg's. The two can race and if ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a pd which is not initialized yet, leading to crash. The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c \"echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos\" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weight with the following patch applied: > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index fc49be622e05..38d671d5e10c 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol) > \t\tpd->online = false; > \t} > > + if (system_state == SYSTEM_RUNNING) { > + spin_unlock_irq(&q->queue_lock); > + ssleep(1); > + spin_lock_irq(&q->queue_lock); > + } > + > \t/* all allocated, init in the same order */ > \tif (pol->pd_init_fn) > \t\tlist_for_each_entry_reverse(blkg, &q->blkg_list, q_node) I don't see a reason why all pd's should be allocated, initialized and onlined together. The only ordering requirement is that parent blkgs to be initialized and onlined before children, which is guaranteed from the walking order. Let's fix the bug by allocating, initializing and onlining pd for each blkg and holding blkcg->lock over initialization and onlining. This ensures that an installed blkg is always fully initialized and onlined removing the the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53189", "url": "https://ubuntu.com/security/CVE-2026-53189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-52918", "url": "https://ubuntu.com/security/CVE-2026-52918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46160", "url": "https://ubuntu.com/security/CVE-2026-46160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix missing last_unlink_trans update when removing a directory When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path \"/mnt/dir1\" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] \t\tinode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] \t\trdev 0 sequence 2 flags 0x0 [445771.638102] \t\tatime 1775744884.0 [445771.660056] \t\tctime 1775744885.645502983 [445771.660058] \t\tmtime 1775744885.645502983 [445771.660060] \t\totime 1775744884.0 [445771.660062] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] \t\tindex 0 name_len 2 [445771.660066] \titem 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] \t\tlocation key (259 1 0) type 2 [445771.660070] \t\ttransid 9 data_len 0 name_len 4 [445771.660075] \titem 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] \t\tlocation key (257 1 0) type 2 [445771.660077] \t\ttransid 9 data_len 0 name_len 4 [445771.660078] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] \t\tlocation key (257 1 0) type 2 [445771.660080] \t\ttransid 9 data_len 0 name_len 4 [445771.660081] \titem 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] \t\tlocation key (259 1 0) type 2 [445771.660083] \t\ttransid 9 data_len 0 name_len 4 [445771.660084] \titem 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] \t\tinode generation 9 transid 9 size 8 nbytes 0 [445771.660087] \t\tblock group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] \t\trdev 0 sequence 2 flags 0x0 [445771.660089] \t\tatime 1775744885.641174097 [445771.660090] \t\tctime 1775744885.645502983 [445771.660091] \t\tmtime 1775744885.645502983 [445771.660105] \t\totime 1775744885.641174097 [445771.660106] \titem 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] \t\tindex 2 name_len 4 [445771.660108] \titem 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] \t\tlocation key (2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46292", "url": "https://ubuntu.com/security/CVE-2026-46292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46159", "url": "https://ubuntu.com/security/CVE-2026-46159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46191", "url": "https://ubuntu.com/security/CVE-2026-46191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46116", "url": "https://ubuntu.com/security/CVE-2026-46116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: \tif (x->km.seq) \t\thlist_del_rcu(&x->byseq); \tif (x->id.spi) \t\thlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46193", "url": "https://ubuntu.com/security/CVE-2026-46193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46180", "url": "https://ubuntu.com/security/CVE-2026-46180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31709", "url": "https://ubuntu.com/security/CVE-2026-31709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-46196", "url": "https://ubuntu.com/security/CVE-2026-46196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46291", "url": "https://ubuntu.com/security/CVE-2026-46291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46090", "url": "https://ubuntu.com/security/CVE-2026-46090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 (\"ALSA: aloop: Fix racy access at PCM trigger\") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46052", "url": "https://ubuntu.com/security/CVE-2026-46052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are unhashed Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume \"negative\" also means \"unhashed\": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45999", "url": "https://ubuntu.com/security/CVE-2026-45999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: \"outpages - inpages\" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46103", "url": "https://ubuntu.com/security/CVE-2026-46103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46056", "url": "https://ubuntu.com/security/CVE-2026-46056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46299", "url": "https://ubuntu.com/security/CVE-2026-46299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: \t========================= \tWARNING: held lock freed! \t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted \t------------------------- \tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! \tffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \t2 locks held by mount/174: \t#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 \t#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \tstack backtrace: \tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tCall Trace: \t \tdump_stack_lvl+0x82/0xd0 \tdebug_check_no_locks_freed+0x13a/0x180 \tkfree+0x16b/0x510 \t? hfsplus_fill_super+0xcb4/0x18a0 \thfsplus_fill_super+0xcb4/0x18a0 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x65f/0xc30 \t? srso_return_thunk+0x5/0x5f \t? pointer+0x4ce/0xbf0 \t? trace_contention_end+0x11c/0x150 \t? __pfx_pointer+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x79b/0xc30 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? vsnprintf+0x6da/0x1270 \t? srso_return_thunk+0x5/0x5f \t? __mutex_unlock_slowpath+0x157/0x740 \t? __pfx_vsnprintf+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? mark_held_locks+0x49/0x80 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? irqentry_exit+0x17b/0x5e0 \t? trace_irq_disable.constprop.0+0x116/0x150 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? __pfx_hfsplus_fill_super+0x10/0x10 \tget_tree_bdev_flags+0x302/0x580 \t? __pfx_get_tree_bdev_flags+0x10/0x10 \t? vfs_parse_fs_qstr+0x129/0x1a0 \t? __pfx_vfs_parse_fs_qstr+0x3/0x10 \tvfs_get_tree+0x89/0x320 \tfc_mount+0x10/0x1d0 \tpath_mount+0x5c5/0x21c0 \t? __pfx_path_mount+0x10/0x10 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? kmem_cache_free+0x307/0x540 \t? user_path_at+0x51/0x60 \t? __x64_sys_mount+0x212/0x280 \t? srso_return_thunk+0x5/0x5f \t__x64_sys_mount+0x212/0x280 \t? __pfx___x64_sys_mount+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \tdo_syscall_64+0x111/0x680 \tentry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7ffacad55eae \tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 \tRSP: 002b ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46169", "url": "https://ubuntu.com/security/CVE-2026-46169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45991", "url": "https://ubuntu.com/security/CVE-2026-45991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46065", "url": "https://ubuntu.com/security/CVE-2026-46065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46086", "url": "https://ubuntu.com/security/CVE-2026-46086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46003", "url": "https://ubuntu.com/security/CVE-2026-46003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46038", "url": "https://ubuntu.com/security/CVE-2026-46038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46026", "url": "https://ubuntu.com/security/CVE-2026-46026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46091", "url": "https://ubuntu.com/security/CVE-2026-46091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46078", "url": "https://ubuntu.com/security/CVE-2026-46078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46069", "url": "https://ubuntu.com/security/CVE-2026-46069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46021", "url": "https://ubuntu.com/security/CVE-2026-46021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46092", "url": "https://ubuntu.com/security/CVE-2026-46092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: check for PCI upstream bridge existence pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31700", "url": "https://ubuntu.com/security/CVE-2026-31700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31712", "url": "https://ubuntu.com/security/CVE-2026-31712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require minimum ACE size in smb_check_perm_dacl() Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31708", "url": "https://ubuntu.com/security/CVE-2026-31708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43350", "url": "https://ubuntu.com/security/CVE-2026-43350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: require a full NFS mode SID before reading mode bits parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31711", "url": "https://ubuntu.com/security/CVE-2026-31711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix active_num_conn leak on transport allocation failure Commit 77ffbcac4e56 (\"smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with \"Limit the maximum number of connections\". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31715", "url": "https://ubuntu.com/security/CVE-2026-31715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() The xfstests case \"generic/107\" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43492", "url": "https://ubuntu.com/security/CVE-2026-43492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting \"lzeros\" from the unsigned \"nbytes\". For this to happen, the scatterlist \"sgl\" needs to occupy more bytes than the \"nbytes\" parameter and the first \"nbytes + 1\" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than \"nbytes\", subtract the number of zeroes from \"nbytes\" and cause the underflow. When commit 2d4d1eea540b (\"lib/mpi: Add mpi sgl helpers\") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to \"nbytes\". However since commit 63ba4d67594a (\"KEYS: asymmetric: Use new crypto interface without scatterlists\"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger \"out_len\" than \"in_len\" and filling the \"in\" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the \"src\" and \"dst\" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "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.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-52933", "url": "https://ubuntu.com/security/CVE-2026-52933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix signed comparison in io_poll_get_ownership() io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2025-22026", "url": "https://ubuntu.com/security/CVE-2025-22026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2023-54125", "url": "https://ubuntu.com/security/CVE-2023-54125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Return error for inconsistent extended attributes ntfs_read_ea is called when we want to read extended attributes. There are some sanity checks for the validity of the EAs. However, it fails to return a proper error code for the inconsistent attributes, which might lead to unpredicted memory accesses after return. [ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0 [ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199 [ 138.931132] [ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4 [ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 138.947327] Call Trace: [ 138.949557] [ 138.951539] dump_stack_lvl+0x4d/0x67 [ 138.956834] print_report+0x16f/0x4a6 [ 138.960798] ? ntfs_set_ea+0x453/0xbf0 [ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200 [ 138.969793] ? ntfs_set_ea+0x453/0xbf0 [ 138.973523] kasan_report+0xb8/0x140 [ 138.976740] ? ntfs_set_ea+0x453/0xbf0 [ 138.980578] __asan_store4+0x76/0xa0 [ 138.984669] ntfs_set_ea+0x453/0xbf0 [ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10 [ 138.993390] ? kernel_text_address+0xd3/0xe0 [ 138.998270] ? __kernel_text_address+0x16/0x50 [ 139.002121] ? unwind_get_return_address+0x3e/0x60 [ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 139.010177] ? arch_stack_walk+0xa2/0x100 [ 139.013657] ? filter_irq_stacks+0x27/0x80 [ 139.017018] ntfs_setxattr+0x405/0x440 [ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10 [ 139.026569] ? kvmalloc_node+0x2d/0x120 [ 139.030329] ? kasan_save_stack+0x41/0x60 [ 139.033883] ? kasan_save_stack+0x2a/0x60 [ 139.037338] ? kasan_set_track+0x29/0x40 [ 139.040163] ? kasan_save_alloc_info+0x1f/0x30 [ 139.043588] ? __kasan_kmalloc+0x8b/0xa0 [ 139.047255] ? __kmalloc_node+0x68/0x150 [ 139.051264] ? kvmalloc_node+0x2d/0x120 [ 139.055301] ? vmemdup_user+0x2b/0xa0 [ 139.058584] __vfs_setxattr+0x121/0x170 [ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10 [ 139.066282] __vfs_setxattr_noperm+0x97/0x300 [ 139.070061] __vfs_setxattr_locked+0x145/0x170 [ 139.073580] vfs_setxattr+0x137/0x2a0 [ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10 [ 139.080223] ? __kasan_check_write+0x18/0x20 [ 139.084234] do_setxattr+0xce/0x150 [ 139.087768] setxattr+0x126/0x140 [ 139.091250] ? __pfx_setxattr+0x10/0x10 [ 139.094948] ? __virt_addr_valid+0xcb/0x140 [ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330 [ 139.102688] ? debug_smp_processor_id+0x1b/0x30 [ 139.105985] ? kasan_quarantine_put+0x5b/0x190 [ 139.109980] ? putname+0x84/0xa0 [ 139.113886] ? __kasan_slab_free+0x11e/0x1b0 [ 139.117961] ? putname+0x84/0xa0 [ 139.121316] ? preempt_count_sub+0x1c/0xd0 [ 139.124427] ? __mnt_want_write+0xae/0x100 [ 139.127836] ? mnt_want_write+0x8f/0x150 [ 139.130954] path_setxattr+0x164/0x180 [ 139.133998] ? __pfx_path_setxattr+0x10/0x10 [ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10 [ 139.141299] ? debug_smp_processor_id+0x1b/0x30 [ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80 [ 139.150796] __x64_sys_setxattr+0x71/0x90 [ 139.155407] do_syscall_64+0x3f/0x90 [ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 139.163843] RIP: 0033:0x7f108cae4469 [ 139.166481] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc [ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469 [ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6 [ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618 [ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0 [ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15 ---truncated---", "cve_priority": "high", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2026-31449", "url": "https://ubuntu.com/security/CVE-2026-31449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: validate p_idx bounds in ext4_ext_correct_indexes ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level. If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read. Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "high", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43064", "url": "https://ubuntu.com/security/CVE-2026-43064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix not releasing workqueue on .release() The workqueue associated with an DSA/IAA device is not released when the object is freed.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165588, 2166457, 1786013, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2163508, 2164699, 1961566, 1956562, 2164516, 2137199, 2165170, 2165170, 2165166, 2165125, 2165125, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2164800 ], "changes": [ { "cves": [ { "cve": "CVE-2026-64582", "url": "https://ubuntu.com/security/CVE-2026-64582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix a use-after-free problem in rxe_mmap rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1: list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */ ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */ [...] rxe_vma_open(vma); /* kref_get, ref → 2 */ remap_vmalloc_range_partial() walks PTEs without any lock. A concurrent DESTROY_CQ ioctl on another CPU calls: kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */ vfree(ip->obj) /* clears vmalloc PTEs mid-walk */ kfree(ip) /* frees rxe_mmap_info */ This yields: 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF. It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get). The call trace are as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:validate_page_before_insert+0x32/0x300 Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5 RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00 R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20 FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0 Call Trace: insert_page+0x8f/0x190 ? __pfx_insert_page+0x10/0x10 ? kasan_save_alloc_info+0x38/0x60 vm_insert_page+0x2e7/0x400 remap_vmalloc_range_partial+0x212/0x3e0 remap_vmalloc_range+0x6e/0xb0 ? __kasan_check_write+0x14/0x30 rxe_mmap+0x2e9/0x5d0 ib_uverbs_mmap+0x1ad/0x2c0 __mmap_region+0x12c2/0x2ad0 ? __pfx___mmap_region+0x10/0x10 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_prev_slot+0x360/0x39c0 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_next_slot+0x1e5b/0x2f40 ? __sanitizer_cov_trace_cmp8+0x18/0x30 ? unmapped_area_topdown+0x4dd/0x610 ? kfree+0x1b1/0x440 ? free_cpumask_var+0x16/0x30 ? __kasan_slab_free+0x7d/0xa0 ? __sanitizer_cov_trace_cmp8+0x18/0x30 mmap_region+0x2e6/0x3c0 do_mmap+0xa3e/0x12a0 ? __pfx_do_mmap+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? down_write_killable+0xba/0x160 ? __pfx_down_write_killable+0x10/0x10 ? __sanitizer_cov_trace_cmp4+0x16/0x30 vm_mmap_pgoff+0x2d4/0x4a0 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x1bf/0x270 ksys_mmap_pgoff+0x40c/0x690 ? __sanitizer_cov_trace_const_cmp4+0x16/0x30 ? __pfx_ksys_mmap_pgoff+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? _raw_spin_trylock+0xbb/0x130 ? __pfx__raw_spin_trylock+0x10/0x10 __x64_sys_mmap+0x135/0x1e0 x64_sys_c ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-05 12:18:00 UTC" }, { "cve": "CVE-2026-74468", "url": "https://ubuntu.com/security/CVE-2026-74468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 (\"gpio: sch: use raw_spinlock_t in the irq startup path\") and commit 90f0109019e6 (\"gpio: eic-sprd: use raw_spinlock_t in the irq startup path\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74482", "url": "https://ubuntu.com/security/CVE-2026-74482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74443", "url": "https://ubuntu.com/security/CVE-2026-74443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at \t(unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74444", "url": "https://ubuntu.com/security/CVE-2026-74444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes \tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74453", "url": "https://ubuntu.com/security/CVE-2026-74453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the \"Auto-initialise Tile State Data Array\" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74455", "url": "https://ubuntu.com/security/CVE-2026-74455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: validate uCAN receive record lengths pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74456", "url": "https://ubuntu.com/security/CVE-2026-74456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 (\"net: usb: lan78xx: Fix double free issue with interrupt buffer allocation\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74457", "url": "https://ubuntu.com/security/CVE-2026-74457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74458", "url": "https://ubuntu.com/security/CVE-2026-74458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74459", "url": "https://ubuntu.com/security/CVE-2026-74459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74460", "url": "https://ubuntu.com/security/CVE-2026-74460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74461", "url": "https://ubuntu.com/security/CVE-2026-74461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74463", "url": "https://ubuntu.com/security/CVE-2026-74463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74464", "url": "https://ubuntu.com/security/CVE-2026-74464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74465", "url": "https://ubuntu.com/security/CVE-2026-74465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the \"hash\" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68451", "url": "https://ubuntu.com/security/CVE-2026-68451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA ECC private key requests cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "high", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68452", "url": "https://ubuntu.com/security/CVE-2026-68452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-74467", "url": "https://ubuntu.com/security/CVE-2026-74467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Check CAP_NET_ADMIN for private ioctls Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74469", "url": "https://ubuntu.com/security/CVE-2026-74469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74471", "url": "https://ubuntu.com/security/CVE-2026-74471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Check return value of __register_event() in trace_module_add_events() trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74473", "url": "https://ubuntu.com/security/CVE-2026-74473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74475", "url": "https://ubuntu.com/security/CVE-2026-74475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74478", "url": "https://ubuntu.com/security/CVE-2026-74478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: vector: fix use-after-free in vector_mmsg_rx() When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: \tif (header_check < 0) { \t\tdev_kfree_skb_irq(skb); \t\tvp->estats.rx_encaps_errors++; \t\tcontinue; \t} The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: \t(*skbuff_vector) = NULL; \tmmsg_vector++; \tskbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74480", "url": "https://ubuntu.com/security/CVE-2026-74480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74481", "url": "https://ubuntu.com/security/CVE-2026-74481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74485", "url": "https://ubuntu.com/security/CVE-2026-74485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: reject a flag character as the field delimiter The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: \tmemset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering \tPaPEPPxPPiP with 'P' as the delimiter (name \"a\", type extension, magic \"x\", interpreter \"i\", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74488", "url": "https://ubuntu.com/security/CVE-2026-74488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: \trx_skb = __skb_dequeue(&list); \trx_hdr = (struct rx_packet_hdr *)rx_skb->data; \tif (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && \t ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { \t\tmwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, \t\t\t\t\t\t skb->len); \t} The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with \tif (!reuse_skb) \t\tdev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes \ties_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, \tfor (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { \t\tu8 ie_len = pos[1]; \t\tif (pos + 2 + ie_len > end) \t\t\tbreak; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74490", "url": "https://ubuntu.com/security/CVE-2026-74490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74492", "url": "https://ubuntu.com/security/CVE-2026-74492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: do not update comments from kernel-side hash adds mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74493", "url": "https://ubuntu.com/security/CVE-2026-74493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket use-after-free during link group termination __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74495", "url": "https://ubuntu.com/security/CVE-2026-74495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74497", "url": "https://ubuntu.com/security/CVE-2026-74497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74498", "url": "https://ubuntu.com/security/CVE-2026-74498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74499", "url": "https://ubuntu.com/security/CVE-2026-74499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() snd_usbmidi_akai_output() computes its fill-loop bound \tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74505", "url": "https://ubuntu.com/security/CVE-2026-74505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74507", "url": "https://ubuntu.com/security/CVE-2026-74507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74508", "url": "https://ubuntu.com/security/CVE-2026-74508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74512", "url": "https://ubuntu.com/security/CVE-2026-74512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74518", "url": "https://ubuntu.com/security/CVE-2026-74518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocate_file_region_entries() allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74519", "url": "https://ubuntu.com/security/CVE-2026-74519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-74523", "url": "https://ubuntu.com/security/CVE-2026-74523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74525", "url": "https://ubuntu.com/security/CVE-2026-74525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: free TX rings on RX allocation failure When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74540", "url": "https://ubuntu.com/security/CVE-2026-74540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74546", "url": "https://ubuntu.com/security/CVE-2026-74546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74547", "url": "https://ubuntu.com/security/CVE-2026-74547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74548", "url": "https://ubuntu.com/security/CVE-2026-74548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix UAF of txrx_stats in nv_remove nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74549", "url": "https://ubuntu.com/security/CVE-2026-74549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74556", "url": "https://ubuntu.com/security/CVE-2026-74556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74557", "url": "https://ubuntu.com/security/CVE-2026-74557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: \tsenselen = get_unaligned_be16(data); \tif (datalen < senselen) \t\tgoto invalid_datalen; \tmemcpy(sc->sense_buffer, data + 2, \t min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74563", "url": "https://ubuntu.com/security/CVE-2026-74563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74579", "url": "https://ubuntu.com/security/CVE-2026-74579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes.", "cve_priority": "medium", "cve_public_date": "2026-08-17 06:19:00 UTC" }, { "cve": "CVE-2026-74564", "url": "https://ubuntu.com/security/CVE-2026-74564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74566", "url": "https://ubuntu.com/security/CVE-2026-74566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: make keyring key-chunk byte order agree with keyring_diff_objects() keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74567", "url": "https://ubuntu.com/security/CVE-2026-74567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74569", "url": "https://ubuntu.com/security/CVE-2026-74569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and \"datalen = datalen + diff - msglen\" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-43491", "url": "https://ubuntu.com/security/CVE-2026-43491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-74577", "url": "https://ubuntu.com/security/CVE-2026-74577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: \tr = nlmsg_data(nlh); \tr->rtm_family\t = AF_MPLS; \tr->rtm_dst_len\t= 20; \tr->rtm_src_len\t= 0; \tr->rtm_table\t= RT_TABLE_MAIN; \tr->rtm_type\t= RTN_UNICAST; \tr->rtm_scope\t= RT_SCOPE_UNIVERSE; \tr->rtm_protocol = rt->rt_protocol; \tr->rtm_flags\t= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64543", "url": "https://ubuntu.com/security/CVE-2026-64543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix use-after-free of the discoverer in tipc_disc_rcv() bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(), but tipc_disc_rcv() still dereferences b->disc in RX softirq under rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv). L2 bearers are safe thanks to the synchronize_net() in tipc_disable_l2_media(), but the UDP bearer defers that call to the cleanup_bearer() workqueue, so the discoverer is freed with no grace period: BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149) Read of size 8 at addr ffff88802348b728 by task poc_tipc/184 tipc_disc_rcv (net/tipc/discover.c:149) tipc_rcv (net/tipc/node.c:2126) tipc_udp_recv (net/tipc/udp_media.c:391) udp_rcv (net/ipv4/udp.c:2643) ip_local_deliver_finish (net/ipv4/ip_input.c:241) Freed by task 181: kfree (mm/slub.c:6565) bearer_disable (net/tipc/bearer.c:418) tipc_nl_bearer_disable (net/tipc/bearer.c:1001) The bearer is freed with kfree_rcu(); free the discoverer the same way. Add an rcu_head to struct tipc_discoverer and free it and its skb from an RCU callback. Because the RCU callback (tipc_disc_free_rcu) lives in module text, a call_rcu() that is still pending when the tipc module is unloaded would invoke a freed function. Add an rcu_barrier() to tipc_exit() after the bearer subsystem has been torn down, so all pending discoverer callbacks have run before the module text goes away. Reachable from an unprivileged user namespace: the TIPCv2 genl family is netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC and CONFIG_TIPC_MEDIA_UDP.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72123", "url": "https://ubuntu.com/security/CVE-2026-72123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 (\"can: bcm: use call_rcu() instead of costly synchronize_rcu()\") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a \"scheduling while atomic\" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72019", "url": "https://ubuntu.com/security/CVE-2026-72019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d (\"macvlan: do not assume mac_header is set in macvlan_broadcast()\") for exactly this purpose.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-52977", "url": "https://ubuntu.com/security/CVE-2026-52977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-72282", "url": "https://ubuntu.com/security/CVE-2026-72282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72068", "url": "https://ubuntu.com/security/CVE-2026-72068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64301", "url": "https://ubuntu.com/security/CVE-2026-64301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error path where process_scmi_regulator_of_node() fails, the function returns without calling of_node_put() on the child node, leaking the reference. Add of_node_put(np) on the error path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64304", "url": "https://ubuntu.com/security/CVE-2026-64304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - validate RSA CRT component lengths The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64593", "url": "https://ubuntu.com/security/CVE-2026-64593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not trim a device which is not writeable [BUG] There is a bug report that btrfs/242 can randomly fail with the following NULL pointer dereference: run fstests btrfs/242 at 2026-06-01 10:25:08 BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609) BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874 BTRFS info (device sdc): using crc32c checksum algorithm BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS info (device sdc): allowing degraded mounts BTRFS info (device sdc): turning on async discard BTRFS info (device sdc): enabling free space tree Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000 CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_trim_fs+0x34c/0xa00 [btrfs] lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs] Call trace: btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P) btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] __arm64_sys_ioctl+0xac/0x108 invoke_syscall.constprop.0+0x5c/0xd0 el0_svc_common.constprop.0+0x40/0xf0 do_el0_svc+0x24/0x40 el0_svc+0x40/0x1d0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00) ---[ end trace 0000000000000000 ]--- Also the reporter is very kind to test the following ASSERT() added to btrfs_trim_free_extents_throttle(): \tASSERT(device->bdev, \t \"devid=%llu path=%s dev_state=0x%lx\\n\", \t device->devid, btrfs_dev_name(device), device->dev_state); And it shows the following output: assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82) Which means the device->bdev is NULL, and the dev_state is BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without BTRFS_DEV_STATE_WRITEABLE flag set. [CAUSE] The pc points to the following call chain: btrfs_trim_fs() |- btrfs_trim_free_extents() |- btrfs_trim_free_extents_throttle() |- bdev_max_discard_sectors(device->bdev) So the NULL pointer dereference is caused by device->bdev being NULL. This looks impossible by a quick glance, as just before calling btrfs_trim_free_extents_throttle(), we have skipped any device that has BTRFS_DEV_STATE_MISSING flag set. However in this particular case, there is a window where the missing device is later re-scanned, causing btrfs to remove the BTRFS_DEV_STATE_MISSING flag: btrfs_control_ioctl() |- btrfs_scan_one_device() |- device_list_add() |- rcu_assign_pointer(device->name, name); | This updates the missing device's path to the new good path. | |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state) This removes the BTRFS_DEV_STATE_MISSING flag. This allows the missing device to re-appear and clear the BTRFS_DEV_STATE_MISSING flag. However the device still does not have the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated. The bdev pointer remains NULL, triggering the crash later. [FIX] This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and device->bdev pointer, and shows a gap in btrfs's re-appearing-device handling. The proper handling of re-appearing device will need quite some extra work, which is out of the context of this small ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64594", "url": "https://ubuntu.com/security/CVE-2026-64594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: initialize reset_work at allocation time ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on ffs->reset_work when a functionfs instance is unmounted: \tffs_data_reset(ffs); \tcancel_work_sync(&ffs->reset_work); However ffs->reset_work is only ever initialized via INIT_WORK() in ffs_func_set_alt() and ffs_func_disable(), and only on the FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed() when the instance is mounted with the \"no_disconnect\" option, so for the common case (no \"no_disconnect\", or mounted and unmounted without ever being deactivated) reset_work is never initialized. ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch it either, so reset_work.func is left NULL. cancel_work_sync() on such a work then trips the WARN_ON(!work->func) guard in __flush_work(): WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flush_work cancel_work_sync ffs_fs_kill_sb [usb_f_fs] deactivate_locked_super deactivate_super cleanup_mnt __cleanup_mnt task_work_run exit_to_user_mode_loop el0_svc On older kernels cancel_work_sync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization. Initialize reset_work once in ffs_data_new() so it is always valid for the lifetime of the ffs_data, and drop the now-redundant INIT_WORK() calls from the two deactivation paths.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68456", "url": "https://ubuntu.com/security/CVE-2026-68456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect() ueagle-atm uses the asynchronous request_firmware_nowait() in .probe(), but does not wait for its completion, not even in .disconnect(); so, if the device is unplugged meanwhile, its teardown runs concurrently with that. Even though this inconsistency is worth addressing on its own, it has also triggered several bug reports in syzbot over the years (some auto-closed) where the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER) creates a firmware subdirectory in the device directory during its removal, which might hit unexpected conditions in kernfs, apparently, depending at which point the add and remove operations raced. (See links.) The pattern is: usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2 usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw Call trace: ... kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs _request_firmware request_firmware_work_func ... (Some variations are observed, after fw_load_sysfs_fallback(), e.g., [1].) While the kernfs side is being looked at, the ueagle-atm side can be fixed by waiting for the pre-firmware load in the .disconnect() handler. This change has a similar approach to previous work by Andrey Tsygunka [2] (wait_for_completion() in .disconnect()), but it is relatively different in design/implementation; using the Originally-by tag for credit assignment. This has been tested with: - synthetic reproducer to check the error path; - USB gadget (virtual device) to check the firmware upload path; - QEMU device emulator to check the device ID re-enumeration path; (The latter two were written by Claude; no other code/text in this commit.) Links (year first reported): 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd4 2024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84d86f0d71394829df6fc53daf6642c045983881 2021 https://syzbot.org/bug?id=3302dc1c0e2b9c94f2e8edb404eabc9267bc6f90 [1] https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 [2] https://lore.kernel.org/lkml/20250410093146.3776801-2-aitsygunka@yandex.ru/", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-64329", "url": "https://ubuntu.com/security/CVE-2026-64329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled. The probe error path already orders free_irq() before ucsi_destroy(). This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64352", "url": "https://ubuntu.com/security/CVE-2026-64352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to \"c || rcu_read_lock_held()\", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64355", "url": "https://ubuntu.com/security/CVE-2026-64355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject fragmented frames in devmap Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64361", "url": "https://ubuntu.com/security/CVE-2026-64361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length check_and_correct_requested_length() compares (off + len) against node_size using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfs_brec_remove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail. For example, with off=14 and len=0xFFFFFFF2 (underflowed from data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6, which is less than a typical node_size of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer. Fix this by widening the addition to u64 before comparing against node_size. This prevents the u32 wrap while keeping the logic straightforward.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64363", "url": "https://ubuntu.com/security/CVE-2026-64363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: appleir: fix UAF on pending key_up_timer in remove() appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 (\"HID: appletb-kbd: fix UAF in inactivity-timer cleanup path\") and has been present since the driver was introduced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64371", "url": "https://ubuntu.com/security/CVE-2026-64371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (part 1) Fix the easy cases where procfs currently calls ptrace_may_access() without exec_update_lock protection, where the fix is to simply add the extra lock or use mm_access(): - do_task_stat(): grab exec_update_lock - proc_pid_wchan(): grab exec_update_lock - proc_map_files_lookup(): use mm_access() instead of get_task_mm() - proc_map_files_readdir(): use mm_access() instead of get_task_mm() - proc_ns_get_link(): grab exec_update_lock - proc_ns_readlink(): grab exec_update_lock", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64364", "url": "https://ubuntu.com/security/CVE-2026-64364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix out-of-bounds bit access on mt_io_flags mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG. As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs \tfor (i = 0; i < mt->num_slots; i++) \t\tclear_bit(i, &td->mt_io_flags); with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received). The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required. Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two \"mt_io_flags & MT_IO_SLOTS_MASK\" arming checks become bitmap_empty(td->active_slots, td->maxcontacts). Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64375", "url": "https://ubuntu.com/security/CVE-2026-64375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (FD links) proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways. To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link().", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64390", "url": "https://ubuntu.com/security/CVE-2026-64390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: track the connection owning a byte-range lock SMB2_LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llist_lock. With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbd_lock and struct file_lock objects. Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llist_lock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-31610", "url": "https://ubuntu.com/security/CVE-2026-31610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: \tif (conn->use_spnego && conn->mechToken) { \t\tkfree(conn->mechToken); \t\tconn->mechToken = NULL; \t} so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-64380", "url": "https://ubuntu.com/security/CVE-2026-64380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: harden POSIX SID length parsing posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64379", "url": "https://ubuntu.com/security/CVE-2026-64379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: mask server-provided mode to 07777 in modefromsid When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64401", "url": "https://ubuntu.com/security/CVE-2026-64401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: resolve SWN tcon from live registrations cifs_swn_notify() looks up a witness registration by id under cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifs_get_swn_reg() lets multiple tcons for the same net/share name share one registration id. A same-share second mount can keep the cifs_swn_reg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tc_lock or incrementing tc_count through swnreg->tcon only moves the use-after-free earlier. Taking tc_lock while holding cifs_swnreg_idr_mutex also violates the documented CIFS lock order. Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifs_tcp_ses_lock -> tc_lock order. The notification path uses that pinned tcon directly and drops the reference when done. Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifs_swn_unregister() while the registration is still protected by cifs_swnreg_idr_mutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings. This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENT_MOVE ordering for the representative tcon because the old-IP unregister is sent before cifs_swn_register() sends the new-IP register.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64381", "url": "https://ubuntu.com/security/CVE-2026-64381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix next buffer leak in receive_encrypted_standard() receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64206", "url": "https://ubuntu.com/security/CVE-2026-64206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64413", "url": "https://ubuntu.com/security/CVE-2026-64413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: zero chainstack array sashiko reports: looking at ebtables table translation, could a sparse cpu_possible_mask lead to an uninitialized pointer free? If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1]. Not a real-world bug, such allocation isn't expected to fail in the first place.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64428", "url": "https://ubuntu.com/security/CVE-2026-64428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: sch: use raw_spinlock_t in the irq startup path sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64438", "url": "https://ubuntu.com/security/CVE-2026-64438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix VF2PF work teardown race in adf_disable_sriov() The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adf_accel_vf_info). Currently, adf_disable_sriov() destroys per-VF mutexes and frees vf_info without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory. This manifests as a use-after-free when KASAN is enabled: BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] Call Trace: kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vf_info is destroyed. Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64441", "url": "https://ubuntu.com/security/CVE-2026-64441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr() Three IE/attribute parsing functions have missing bounds checks. rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtw_get_sec_ie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain. rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at entry, before verifying that wps_ielen is large enough to contain the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside the attribute loop, get_unaligned_be16() is called on attr_ptr and attr_ptr+2 without checking that 4 bytes remain in the buffer. Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie() and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum IE length requirement, add a wps_ielen < 6 early return in rtw_get_wps_attr(), and add a 4-byte bounds check in its inner loop.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64461", "url": "https://ubuntu.com/security/CVE-2026-64461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64446", "url": "https://ubuntu.com/security/CVE-2026-64446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie() supplicant_ie is a 256-byte array in struct security_priv. The WPA and WPA2 IE copy paths use: memcpy(padapter->securitypriv.supplicant_ie, &pwpa[0], wpa_ielen + 2); where wpa_ielen is the raw IE length field (u8, 0-255). When a local user supplies a connect request via nl80211 with a crafted WPA IE of length 255, wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into the adjacent last_mic_err_time field. rtw_parse_wpa_ie() does not prevent this: its length consistency check compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255 when wpa_ie_len = 257, so the check passes silently. Add explicit bounds checks for both the WPA and WPA2 paths before the memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the supplicant_ie buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64448", "url": "https://ubuntu.com/security/CVE-2026-64448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: restrict implied bcc[0] exemption to responses without data area smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received (\"server can return one byte more due to implied bcc[0]\"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, yet smb2_check_message() still accepts it. The subsequent decoder then reads past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server; both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders are affected: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00 Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81 CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 asn1_ber_decoder+0x16a7/0x1b00 decode_negTokenInit+0x19/0x30 SMB2_negotiate+0x31d9/0x4c90 cifs_negotiate_protocol+0x1f2/0x3f0 cifs_get_smb_ses+0x93f/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 85: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 0 bytes to the right of allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0) which belongs to the cache cifs_small_rq of size 448 BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50 Read of size 329 at addr ffff88800726c678 by task mount.cifs/89 CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x36/0x50 decode_ntlmssp_challenge+0x457/0x680 SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0 SMB2_sess_setup+0x219/0x4f0 cifs_setup_session+0x248/0xaf0 cifs_get_smb_ses+0xf79/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 93: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 120 bytes inside of allocated 448-byte region [ffff88800726c600, ffff88800726c7c0) which belongs to the cache cifs_small_rq of size 448 Restrict the +1 exemption to responses that have no data area, so that it still covers the bcc[0] omission it was meant for. When a data area is present, the +1 discrepancy instead means the reported data length overruns the ---truncated---", "cve_priority": "negligible", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64462", "url": "https://ubuntu.com/security/CVE-2026-64462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64475", "url": "https://ubuntu.com/security/CVE-2026-64475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Release the VGA arbiter client on register_device() failure The re-order in the Fixes commit below displaced vfio_pci_vga_init() as the last failure point of what is now vfio_pci_core_register_device() without introducing an unwind for the VGA arbiter registration. In current kernels this is mostly benign because vfio_pci_set_decode() only uses pci_dev state, but the original failure path could leave a callback with a freed vdev cookie. The stale registration also becomes unsafe again once the callback follows drvdata to the vfio device. Add the required VGA unwind callout.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64488", "url": "https://ubuntu.com/security/CVE-2026-64488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return early if any fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64510", "url": "https://ubuntu.com/security/CVE-2026-64510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64512", "url": "https://ubuntu.com/security/CVE-2026-64512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Suppress UBSAN warning caused by field misuse The definition of reg->access_width changes depending on the reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses access_width to indicate the PCC region, which can result in a UBSAN if the value is greater than 4. For example: UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9 shift exponent 32 is too large for 32-bit type 'int' CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy) Hardware name: To be filled by O.E.M. Call trace: ...(trimming) ubsan_epilogue+0x10/0x48 __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ... (trimming) Lets fix this by validating the region type, as well as whether access_width has a value. Then since we are returning bit_width directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting the size.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68466", "url": "https://ubuntu.com/security/CVE-2026-68466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68467", "url": "https://ubuntu.com/security/CVE-2026-68467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mchp23k256: use SPI match data for chip caps The driver stores chip capacity information in both the OF match table and the SPI id table. Probe currently uses of_device_get_match_data(), so a non-OF SPI modalias match falls back to mchp23k256_caps even when the SPI id table selected a different part. Use spi_get_device_match_data() so SPI id-table driver_data is consumed when OF match data is absent. This keeps the existing default fallback while avoiding the wrong MTD geometry for id-table-only matches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68469", "url": "https://ubuntu.com/security/CVE-2026-68469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix permanently busy scans after multiple roam iterations In order for the firmware to sleep, the driver has to confirm a previously received sleep request. The normal sequence of evets goes like this: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Before sending the sleep-confirm command, the driver must make sure there are no commands either running or waiting to be completed. mwifiex_ret_802_11_associate() unconditionally sets ps_state = PS_STATE_AWAKE when it processes the association command response, outside of the normal powersave management flow. If EVENT_SLEEP arrives while the association command is in flight, ps_state is PRE_SLEEP when the association command response is parsed, and the forced AWAKE overwrites it. The deferred sleep-confirm is never sent. A subsequent scan_start command is correctly acknowledged, but the firmware doesn't generate scan_result events. The scan request never finishes, and additional requests from userspace fail with -EBUSY. After testing on both IW412 and W8997, I could only trigger the bug on the IW412 and observed the firmwares behave differently. On the IW412 the firmware still sends EVENT_SLEEP while the authentication / association process is ongoing. A W8997 under the same conditions seems to suppress power-save for the duration of the association, so PRE_SLEEP never coincided with the association response even after extended periods of testing using the loops described below (>12hours). On the IW412, the delay between commands that triggers an EVENT_SLEEP was empirically determined to be ~20ms. This delay can naturally occur when the driver is outputting debugging information (debug_mask = 0x00000037), in which situation the busy scans issue is repeatable while running \"test 1)\" as described below. If the delay between commands is less than ~20ms, the firmware stays awake and the issue was not reproducible running the same test. The host_mlme=false path also behaves differently. In this case, the entire authentication / association transaction is executed by one command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit EVENT_SLEEP while the command is running. Remove the assignment so the ps_state is only manipulated in the paths that are related to powersave event handling and on the main workqueue for correct sleep confirmation. The following loop tests were performed (with debugging output enabled): 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations. Each test ran in each device for at least 3 hours.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68474", "url": "https://ubuntu.com/security/CVE-2026-68474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access() spufs_mem_mmap_access() computes the local store offset as address - vma->vm_start, but bounds-checks it against vma->vm_end instead of the local store size. On 64-bit, offset is always well below vma->vm_end, so the clamp never fires and len stays unbounded against the LS_SIZE buffer returned by ctx->ops->get_ls(). Reject offsets at or beyond LS_SIZE and clamp len to the remaining space, mirroring the guard already used by spufs_mem_mmap_fault() and spufs_ps_fault().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68475", "url": "https://ubuntu.com/security/CVE-2026-68475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: reset: sunxi: fix memory region leak on ioremap failure In sunxi_reset_init(), when ioremap() fails, the memory region obtained via request_mem_region() is not released, leading to a resource leak. Add an err_mem_region label to properly release the memory region before freeing the data structure.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68478", "url": "https://ubuntu.com/security/CVE-2026-68478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memstick: ms_block: reject a card that reports too many blocks msb_ftl_initialize() computes the zone count from the card block count with no bound: \tmsb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; \t... \tfor (i = 0; i < msb->zone_count; i++) \t\tmsb->free_block_count[i] = MS_BLOCKS_IN_ZONE; msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the init loop past the end too. A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68479", "url": "https://ubuntu.com/security/CVE-2026-68479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: validate firmware patch bounds rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup. The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72004", "url": "https://ubuntu.com/security/CVE-2026-72004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix memory leak in ieee80211_register_hw() If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl. Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72005", "url": "https://ubuntu.com/security/CVE-2026-72005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: avoid full teardown before work setup in probe rt2x00lib_probe_dev() uses the full rt2x00lib_remove_dev() teardown for all probe failures. However, drv_data allocation and workqueue allocation can fail before intf_work, autowakeup_work and sleep_work have been initialized. Do not enter the full remove path until the probe has reached the point where those work items are set up. Return directly for drv_data allocation failure, and use a small early cleanup path for workqueue allocation failure. This issue was found by our static analysis tool and then confirmed by manual review of rt2x00lib_probe_dev() and rt2x00lib_remove_dev(). The early probe exits should not call a common teardown path that assumes the later work setup has already completed. A QEMU PoC forced alloc_ordered_workqueue() to fail before the work initializers are reached. The resulting fail path entered rt2x00lib_remove_dev(), and DEBUG_OBJECTS reported invalid work drains with rt2x00lib_probe_dev() and rt2x00lib_remove_dev() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72010", "url": "https://ubuntu.com/security/CVE-2026-72010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72013", "url": "https://ubuntu.com/security/CVE-2026-72013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent NULL pointer dereference in machine_kexec_prepare() A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72021", "url": "https://ubuntu.com/security/CVE-2026-72021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in SCTP state lookup set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header. This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed. Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72022", "url": "https://ubuntu.com/security/CVE-2026-72022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: llc: fix SAP refcount leak in llc_ui_autobind() llc_ui_autobind() opens a SAP after choosing a dynamic LSAP. llc_sap_open() returns a reference owned by the caller, and llc_sap_add_socket() takes a second reference for the socket's membership in the SAP hash tables. llc_ui_bind() drops the caller's reference after adding the socket, but llc_ui_autobind() keeps it. When the socket is closed, llc_sap_remove_socket() releases only the socket reference, leaving the SAP on llc_sap_list with sk_count == 0. This is user-visible because repeated autobind and close cycles can consume all dynamic SAP values and make later autobinds fail with -EUSERS. Drop the caller's reference after a successful autobind, matching llc_ui_bind()'s ownership model.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72024", "url": "https://ubuntu.com/security/CVE-2026-72024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: remove interfaces with RCU list deletion Queue wake, stop, and disable paths walk local->interfaces under RCU. The bulk hardware teardown path removes entries with list_del(), so an asynchronous transmit completion can follow a poisoned list node in ieee802154_wake_queue(). Use list_del_rcu() as in the single-interface removal path. The following unregister_netdevice() waits for in-flight RCU readers before freeing the netdevice, so no separate grace-period wait is needed.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72025", "url": "https://ubuntu.com/security/CVE-2026-72025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/monwriter: Reject buffer reuse with different data length When data buffers are reused, e.g. for interval sample records, the first record determines the data length, and the size of the buffer for user copy. Current monwriter code does not check if the data length was changed for subsequent records, which also would never happen for valid user programs. However, a malicious user could change the data length, resulting in out of bounds user copy to the kernel buffer, and memory corruption. By default, the monwriter misc device is created with root-only permissions, so practical impact is typically low. Fix this by checking for changed data length and rejecting such records.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72036", "url": "https://ubuntu.com/security/CVE-2026-72036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked multiq_dequeue() takes a packet from a band's child with a direct ->dequeue() call after multiq_peek() peeked it. When the child is non-work-conserving the peek stashes the skb in the child's gso_skb, so the direct dequeue returns a different skb and orphans the stash, desyncing the child's qlen/backlog. With a qfq child reached through a peeking parent (e.g. tbf) this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_prio already does and as sch_red and sch_sfb were just fixed to do. The helper is a no-op when the child has no stash, so a work-conserving child is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72038", "url": "https://ubuntu.com/security/CVE-2026-72038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: fix BAR resource leak on PF number failure If cn23xx_get_pf_num() fails, the function returns without unmapping either BAR. Unmap both BARs before returning from the error path. Found by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72039", "url": "https://ubuntu.com/security/CVE-2026-72039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72229", "url": "https://ubuntu.com/security/CVE-2026-72229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: clean untagged VLAN on netdev registration failure When an mesh interface is registered, it creates an untagged struct batadv_meshif_vlan on top of it via the NETDEV_REGISTER notifier. But in this process, another receiver of this notification can veto the registration. The netdev registration will be aborted because of this veto. The register_netdevice() call will try to clean up the net_device using unregister_netdevice_queue() - which only uses the .priv_destructor to free private resources. In this situation, .dellink will not be called. The cleanup of the untagged batadv_meshif_vlan must thefore be done in the destructor to avoid a leak of this object.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72232", "url": "https://ubuntu.com/security/CVE-2026-72232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: ensure minimal ethernet header on TX As documented in commit 8bd67ebb50c0 (\"net: bridge: xmit: make sure we have at least eth header len bytes\"), it is possible by for a local user with eBPF TC hook access to attach a tc filter which truncates the packet and redirects to an batadv interface. But the code assumes that at least ETH_HLEN bytes are available and thus might read outside of the available buffer. The batadv_interface_tx() must therefore always check itself if enough data is available for the ethernet header and don't rely on min_header_len.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72235", "url": "https://ubuntu.com/security/CVE-2026-72235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: retrieve ethhdr after potential skb realloc on RX pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72047", "url": "https://ubuntu.com/security/CVE-2026-72047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72048", "url": "https://ubuntu.com/security/CVE-2026-72048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix cas_ctl leak on spi_async failure ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72049", "url": "https://ubuntu.com/security/CVE-2026-72049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: admin-gate legacy LLSEC dump operations In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM. Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the \"802.15.4 MAC\" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames. Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family. Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry \"can be retrieved by unprivileged users\" annotations).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72052", "url": "https://ubuntu.com/security/CVE-2026-72052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72054", "url": "https://ubuntu.com/security/CVE-2026-72054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72055", "url": "https://ubuntu.com/security/CVE-2026-72055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink vti6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72056", "url": "https://ubuntu.com/security/CVE-2026-72056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ena: clean up XDP TX queues when regular TX setup fails create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72061", "url": "https://ubuntu.com/security/CVE-2026-72061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sit: require CAP_NET_ADMIN in the device netns for changelink ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72066", "url": "https://ubuntu.com/security/CVE-2026-72066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Bound hotplug states sysfs output states_show() adds CPU hotplug state names into a single sysfs buffer using sprintf(). With enough registered states, this can write past the end of the PAGE_SIZE buffer. Use sysfs_emit_at() so output is bounded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72067", "url": "https://ubuntu.com/security/CVE-2026-72067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Preserve per instance callback errors cpuhp_invoke_callback() unwinds earlier callbacks for the same hotplug state when one instance fails. The rollback path currently reuses ret, so a successful rollback can hide the original error and make the failed transition look successful. Keep the rollback result separate from the original error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72074", "url": "https://ubuntu.com/security/CVE-2026-72074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix type confusion in CDC union descriptor parsing The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72076", "url": "https://ubuntu.com/security/CVE-2026-72076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72078", "url": "https://ubuntu.com/security/CVE-2026-72078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - validate control endpoint type The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72079", "url": "https://ubuntu.com/security/CVE-2026-72079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix use-after-free and double-free in disconnect ims_pcu_disconnect() only intended to perform cleanup when the primary (control) interface is unbound. However, it currently relies on the interface class to distinguish between control and data interfaces. A malicious device could present a data interface with the same class as the control interface, leading to premature cleanup and potential use-after-free or double-free. Switch to verifying that the interface being disconnected is indeed the control interface.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72081", "url": "https://ubuntu.com/security/CVE-2026-72081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix I/O leak on unsupported additional CDB efct_dispatch_fcp_cmd() allocates an efct_io before dispatching an unsolicited FCP command. If the command has an unsupported additional CDB, the function returns -EIO before handing the IO to the SCSI layer. Free the allocated IO before returning from this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72082", "url": "https://ubuntu.com/security/CVE-2026-72082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix refcount leak in efct_hw_io_abort() When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object. Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery. Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72086", "url": "https://ubuntu.com/security/CVE-2026-72086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free the command tag on the TMR submit-failure path scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag. Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails. transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req. Use the same helper, which returns just the tag, on this path too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72088", "url": "https://ubuntu.com/security/CVE-2026-72088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72102", "url": "https://ubuntu.com/security/CVE-2026-72102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm_early_create: fix freeing used table on dm_resume failure If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72105", "url": "https://ubuntu.com/security/CVE-2026-72105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-log: fix a bitset_size overflow on 32bit machines Commit c20e36b7631d (\"dm log: fix out-of-bounds write due to region_count overflow\") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72107", "url": "https://ubuntu.com/security/CVE-2026-72107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix out-of-bounds memory access for non-zero start sector dm-era tracks writes in target-relative blocks, but era_map() calculates the writeset block before applying the target offset. Tables with a non-zero start sector can therefore pass an absolute mapped-device block to metadata_current_marked(). If the absolute block is beyond the current writeset size, writeset_marked() tests past the end of the in-core bitset. KASAN reports this as a vmalloc-out-of-bounds access. Apply the target offset before calculating the era block so writeset lookups use the target-relative block number.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72108", "url": "https://ubuntu.com/security/CVE-2026-72108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm thin metadata: fix metadata snapshot consistency on commit failure __reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata. Reproducer 1: __reserve_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 112 linear /dev/sdc 0 112 3984 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency. dmsetup message tpool 0 \"reserve_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0. Reproducer 2: __release_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 128 linear /dev/sdc 0 128 3968 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata. dmsetup message tpool 0 \"reserve_metadata_snap\" dmsetup message tpool 0 \"release_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked. Fix by deferring the held_root update to commit time. Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72109", "url": "https://ubuntu.com/security/CVE-2026-72109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sparx5: unregister blocking notifier on init failure sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72120", "url": "https://ubuntu.com/security/CVE-2026-72120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu list annotations and operations sashiko-bot remarked the missing use of list_add_rcu() in bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure when bcm_proc_show() traverses the bcm_op's under rcu_read_lock(). To cover all initial settings of the bcm_op's the list_add_rcu() calls are moved to the end of the setup code. While at it, also fix the mirroring removal side: bcm_release() called bcm_remove_op() - which frees the op via call_rcu() - on ops that were still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first. Unlink each op with list_del_rcu() before handing it to bcm_remove_op(), matching the existing pattern in bcm_delete_tx_op()/bcm_delete_rx_op().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72122", "url": "https://ubuntu.com/security/CVE-2026-72122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all mutate both fields under that same lock. Because the lockless reads and the locked writes are unordered with respect to each other, a racing bcm_notify() (device unregister) or bcm_connect() (concurrent bind on another thread sharing the socket) can make bcm_sendmsg() observe an inconsistent combination, e.g. a stale bound=1 together with the now-cleared ifindex=0, silently turning a socket bound to a specific CAN interface into one that also matches \"any\" interface. Keep the lockless bo->bound check purely as a fast-path reject, and move the ifindex read (and a bo->bound re-check) into the locked section, where every writer already serializes. This removes the possibility of observing the two fields torn against each other, rather than trying to fix it with more READ_ONCE()/WRITE_ONCE() pairs on two independently updated fields. Annotate the now-purely-lockless bo->bound accesses consistently across all its write sites. Also fix bcm_rx_setup() silently returning success when the target device disappears concurrently instead of reporting -ENODEV, so a broken RX op is no longer left registered as if it had succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72126", "url": "https://ubuntu.com/security/CVE-2026-72126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72133", "url": "https://ubuntu.com/security/CVE-2026-72133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: Fix completion initialization order before devm_request_irq() The driver calls devm_request_irq() before initializing the completion used by the interrupt handler. Because the interrupt may occur immediately after devm_request_irq(), the handler may execute before init_completion(). This may result in calling complete() on an uninitialized completion, causing undefined behavior. This has been observed with KASAN. Fix this by initializing the completion before registering the IRQ.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72135", "url": "https://ubuntu.com/security/CVE-2026-72135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Make the TPM character devices non-seekable The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset(). Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale. Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged. Tested on Linux 6.12 with KASAN and a swtpm TPM2 device: - sequential partial reads returned the complete response - pread() and preadv() with offset 0x1400 returned -ESPIPE - pwrite() and pwritev() with offset zero returned -ESPIPE - the pending response remained intact after the rejected operations - a subsequent normal command/response cycle completed normally - no KASAN report was produced.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72136", "url": "https://ubuntu.com/security/CVE-2026-72136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72138", "url": "https://ubuntu.com/security/CVE-2026-72138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Fix these issues by properly handling all error cases.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72140", "url": "https://ubuntu.com/security/CVE-2026-72140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource() If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72153", "url": "https://ubuntu.com/security/CVE-2026-72153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72159", "url": "https://ubuntu.com/security/CVE-2026-72159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72160", "url": "https://ubuntu.com/security/CVE-2026-72160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series \"ocfs2: harden inode validators against forged metadata\", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72163", "url": "https://ubuntu.com/security/CVE-2026-72163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72164", "url": "https://ubuntu.com/security/CVE-2026-72164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: avoid moving extents to occupied clusters For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group. The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated. When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run. Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72165", "url": "https://ubuntu.com/security/CVE-2026-72165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: fix condition in 'nand_select_target()' 'cs' here must be in range [0:nanddev_ntargets[.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72166", "url": "https://ubuntu.com/security/CVE-2026-72166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: \terr = io_wait_event_killable(req->wq, ...) \t/* SIGKILL wakes the task, returns -ERESTARTSYS */ \tif (err == -ERESTARTSYS && c->status == Connected && \t\ttype == P9_TFLUSH) { \t\tsigpending = 1; \t\tclear_thread_flag(TIF_SIGPENDING); \t\tgoto again; \t} clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72167", "url": "https://ubuntu.com/security/CVE-2026-72167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72171", "url": "https://ubuntu.com/security/CVE-2026-72171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: slram: remove failed entries from the device list register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72181", "url": "https://ubuntu.com/security/CVE-2026-72181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mips: sched: Fix CPUMASK_OFFSTACK memory corruption This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72182", "url": "https://ubuntu.com/security/CVE-2026-72182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: fix refcount leak in is_full_charged() In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72193", "url": "https://ubuntu.com/security/CVE-2026-72193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: cap RESTART_TABLE free-chain walker at rt->used A crafted NTFS3 disk image triggers an in-kernel infinite loop at mount time, hanging the mounting thread and firing the soft-lockup watchdog within ~22s on multi-CPU hosts (panic with kernel.softlockup_panic=1). The bug is reachable from desktop USB auto-mount on distributions where udisks2 routes the NTFS signature to the in-tree ntfs3 driver (Arch family and an increasing fraction of Fedora / openSUSE / RHEL deployments); CAP_SYS_ADMIN-class manual mount elsewhere. check_rstbl()'s second walker iterates the free-entry singly-linked list headed by rt->first_free with no upper bound on iteration count: for (off = ff; off;) { if (off == RESTART_ENTRY_ALLOCATED) return false; off = le32_to_cpu(*(__le32 *)Add2Ptr(rt, off)); if (off > ts - sizeof(__le32)) return false; } The existing guards cover three exits: end-of-list (off == 0), the in-use marker (off == RESTART_ENTRY_ALLOCATED), and out-of-bounds (off > ts - sizeof(__le32)). None of the three prevents an in-bounds cycle. A crafted on-disk RESTART_TABLE whose free chain contains a self-loop or A->B->A cycle whose offsets satisfy: - in range [sizeof(struct RESTART_TABLE), ts - sizeof(__le32)] - (off - sizeof(struct RESTART_TABLE)) % rsize == 0 passes all existing guards and spins the mount-time thread forever. Reproduced in UML by hand-forging a 2 MB NTFS3 image whose journal RESTART_TABLE first_free = 0x18 and whose entry at offset 0x18 stores 0x18 as its next pointer; mount of the forged image with the in-tree ntfs3 driver never returns. Bound the walker by rt->used. Each entry on a legitimate free chain is unique, and the total slot count is ne = le16_to_cpu (rt->used). A traversal that visits more than ne slots is by construction malformed; reject it as a corrupt RESTART_TABLE. After this patch, mount of the forged image returns with -EINVAL and a log_replay failure message, and mkntfs-produced legitimate images mount cleanly (verified in the same UML harness).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64532", "url": "https://ubuntu.com/security/CVE-2026-64532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation} In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is `Add2Ptr(e, le16_to_cpu(e->view.data_off))`, where e->view.data_off comes from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validates view.data_off + dlen against e->size; the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate the entry's offset, but not its internal view fields. The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <= e->size. Apply the same bound at the two memmove sites. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE. This is similar in shape to Pavitra Jha's 2026-05-02 patch \"fs/ntfs3: prevent oob in case UpdateRecordDataRoot\" (<20260502105008.21827-1-jhapavitra98@gmail.com>) which proposes calling ntfs3_bad_de_range(); that helper does not exist in mainline. This patch uses inline checks.", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64533", "url": "https://ubuntu.com/security/CVE-2026-64533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate lcns_follow in log_replay conversion log_replay() converts DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY records when replaying version 0 restart tables. During this conversion, the memmove() length is derived directly from the on-disk lcns_follow field: \tmemmove(&dp->vcn, &dp0->vcn_low, \t\t2 * sizeof(u64) + \t\t\t\tle32_to_cpu(dp->lcns_follow) * sizeof(u64)); check_rstbl() validates restart table structure, but does not constrain per-entry lcns_follow values relative to the entry size. A malformed filesystem image can provide an oversized lcns_follow value, causing the conversion memmove() to access memory beyond the bounds of the allocated restart table buffer. The same field is later used to bound iteration over page_lcns[], so validating lcns_follow during conversion also prevents downstream out-of-bounds access from the same malformed metadata. Compute the maximum valid lcns_follow from the already-validated restart table entry size and reject entries that exceed this bound. Reuse the existing t16/t32 scratch variables already declared in log_replay() to avoid introducing new declarations. [almaz.alexandrovich@paragon-software.com: fixed the conflicts]", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72195", "url": "https://ubuntu.com/security/CVE-2026-72195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment \tattr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72197", "url": "https://ubuntu.com/security/CVE-2026-72197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: \tif (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || \t Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || \t used + esize > le32_to_cpu(hdr->total)) { \t\tgoto dirty_vol; \t} Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72215", "url": "https://ubuntu.com/security/CVE-2026-72215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002. To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant. Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and \"if it ain't broke, don't fix it,\" so just leave them alone.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72218", "url": "https://ubuntu.com/security/CVE-2026-72218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72219", "url": "https://ubuntu.com/security/CVE-2026-72219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file leak when nlm_do_fopen() fails A client can repeatedly drive nlm_do_fopen() failures by presenting file handles that the underlying export rejects. After kzalloc_obj() succeeds in nlm_lookup_file(), the freshly allocated nlm_file is not yet inserted into nlm_files[]. The nlm_do_fopen() failure path jumps to out_unlock, which releases nlm_file_mutex and returns without freeing the allocation, so each failure leaks one nlm_file. Route the failure through out_free so kfree() runs before the function returns.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72223", "url": "https://ubuntu.com/security/CVE-2026-72223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arena sub-allocations on discover_arenas() error path Memory allocated by btt_freelist_init(), btt_rtt_init(), and btt_maplocks_init() is not freed on some discover_arenas() error paths. This leaks memory when arena discovery fails. Add the missing kfree() calls to release the allocations before returning an error. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72224", "url": "https://ubuntu.com/security/CVE-2026-72224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arenas on btt_init() error paths The arenas allocated by discover_arenas() or create_arenas() are not freed on some error paths in btt_init(). This leaks memory when BTT initialization fails. Call free_arenas() from the affected error paths to release the allocations. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72225", "url": "https://ubuntu.com/security/CVE-2026-72225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit() jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check. The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort. Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72228", "url": "https://ubuntu.com/security/CVE-2026-72228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: fix primary_if leak on failed linearization If the skb has a frag_list, it must be linearized before it can be split using skb_split(). But when this step failed, it must not only free the skb but also take care of the reference to the already found primary_if.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72230", "url": "https://ubuntu.com/security/CVE-2026-72230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72231", "url": "https://ubuntu.com/security/CVE-2026-72231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is \"ret == false\". But the actual implementation is checking for \"ret == true\". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72233", "url": "https://ubuntu.com/security/CVE-2026-72233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: reacquire gw address after skb realloc The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72238", "url": "https://ubuntu.com/security/CVE-2026-72238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/boot: Validate console=uart8250 baud rate to fix early boot hang When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72240", "url": "https://ubuntu.com/security/CVE-2026-72240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72241", "url": "https://ubuntu.com/security/CVE-2026-72241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: uleds: Fix potential buffer overread The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72245", "url": "https://ubuntu.com/security/CVE-2026-72245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64554", "url": "https://ubuntu.com/security/CVE-2026-64554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() br_ip6_fragment() gets prevhdr, a pointer into the skb head, from ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb skb_checksum_help() reallocates the head via pskb_expand_head(), leaving prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a use-after-free write. Save prevhdr's offset before skb_checksum_help() and recompute it after, like commit ef0efcd3bd3f (\"ipv6: Fix dangling pointer when ipv6 fragment\"). BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857) Write of size 1 at addr ffff888013ff5016 by task exploit/141 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip6_frag_next (net/ipv6/ip6_output.c:857) br_ip6_fragment (net/ipv6/netfilter.c:212) nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407) nf_hook_slow (net/netfilter/core.c:619) br_forward_finish (net/bridge/br_forward.c:66) __br_forward (net/bridge/br_forward.c:115) maybe_deliver (net/bridge/br_forward.c:191) br_flood (net/bridge/br_forward.c:245) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:442) ... packet_sendmsg (net/packet/af_packet.c:3114) ... do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72247", "url": "https://ubuntu.com/security/CVE-2026-72247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: fix zone comparison in tuple dedup The \"already exists\" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument. Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone. nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents. Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72250", "url": "https://ubuntu.com/security/CVE-2026-72250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header: \tskb->mac_header += sizeof(struct frag_hdr); On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the \"not set\" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom. The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72256", "url": "https://ubuntu.com/security/CVE-2026-72256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_cluster: reject template conntracks in hash match xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72264", "url": "https://ubuntu.com/security/CVE-2026-72264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tridentfb: fix potential memory leak in trident_pci_probe() In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72265", "url": "https://ubuntu.com/security/CVE-2026-72265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: nvidia: fix potential memory leak in nvidiafb_probe() In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72267", "url": "https://ubuntu.com/security/CVE-2026-72267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: carminefb: fix potential memory leak in alloc_carmine_fb() The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72268", "url": "https://ubuntu.com/security/CVE-2026-72268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe() In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72269", "url": "https://ubuntu.com/security/CVE-2026-72269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: fix potential memory leak in uvesafb_probe() Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. Fix this by updating the goto label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72270", "url": "https://ubuntu.com/security/CVE-2026-72270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: s3fb: fix potential memory leak in s3_pci_probe() In s3_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72271", "url": "https://ubuntu.com/security/CVE-2026-72271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: i740fb: fix potential memory leak in i740fb_probe() In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72272", "url": "https://ubuntu.com/security/CVE-2026-72272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: radeon: fix potential memory leak in radeonfb_pci_register() The function radeonfb_pci_register() allocates memory for modelist (by calling radeon_check_modes() which calls fb_add_videomode()). The memory is appended to info->modelist, but is not freed in subsequent error paths. Fix this by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72274", "url": "https://ubuntu.com/security/CVE-2026-72274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: hecubafb: fix potential memory leak in hecubafb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72275", "url": "https://ubuntu.com/security/CVE-2026-72275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72276", "url": "https://ubuntu.com/security/CVE-2026-72276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: metronomefb: fix potential memory leak in metronomefb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72297", "url": "https://ubuntu.com/security/CVE-2026-72297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72298", "url": "https://ubuntu.com/security/CVE-2026-72298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with \tif (!size || len != ALIGN(size, 4) + hdrlen) \t\tgoto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 (\"net: qrtr: fix OOB Read in qrtr_endpoint_post\"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72306", "url": "https://ubuntu.com/security/CVE-2026-72306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72307", "url": "https://ubuntu.com/security/CVE-2026-72307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree. Fix by reinitializing vr inside the error loop with the updated index: \tvr = &mlxsw_sp->router->vrs[i]; so that the loop correctly iterates over all VRs that were actually replaced.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72310", "url": "https://ubuntu.com/security/CVE-2026-72310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds.", "cve_priority": "negligible", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72314", "url": "https://ubuntu.com/security/CVE-2026-72314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72316", "url": "https://ubuntu.com/security/CVE-2026-72316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix NULL pointer dereference in metadata_open() metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72326", "url": "https://ubuntu.com/security/CVE-2026-72326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cake: reject overhead values that underflow length CAKE accepts signed overhead values and stores them in an s16, but the adjusted packet length calculation uses unsigned arithmetic. A negative effective length can therefore wrap to a large value. Such configurations make rate accounting depend on integer wraparound rather than on the packet size userspace intended to model. A static netlink lower bound is not enough because packets reaching CAKE can be smaller than any reasonable manual-overhead allowance. Fold the signed overhead adjustment into the existing datapath MPU clamp so negative adjusted lengths are clamped before link-layer framing adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64549", "url": "https://ubuntu.com/security/CVE-2026-64549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup() bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length: \tbt_dev_info(hdev, \"%s\", (char *)(skb->data + 1)); \thci_set_fw_info(hdev, \"%s\", skb->data + 1); A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file. Print the revision string with a bounded \"%.*s\" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64550", "url": "https://ubuntu.com/security/CVE-2026-64550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: validate MAP frame length before ingress parsing When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes the skb straight to __rmnet_map_ingress_handler(), skipping the length validation that rmnet_map_deaggregate() performs on the aggregated path. The parser then dereferences the MAP header and csum header/trailer based on the on-wire pkt_len without checking skb->len, so a short frame is read out of bounds: BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet Read of size 1 at addr ffff88801118ed00 by task exploit/147 Call Trace: ... rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413) __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089) netif_receive_skb (net/core/dev.c:6460) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2001) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Factor that validation out of rmnet_map_deaggregate() into rmnet_map_validate_packet_len() and run it on the no-aggregation path too. The MAP header is bounds-checked first, since this path can receive a frame shorter than the header.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72347", "url": "https://ubuntu.com/security/CVE-2026-72347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_connmark: reject invalid shift parameters Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmark_tg_shift(). A shift_bits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shift_dir values are also accepted and silently fall back to the left-shift path. Reject invalid revision-2 shift parameters in connmark_tg_check() so malformed rules fail at installation time, before they can reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72349", "url": "https://ubuntu.com/security/CVE-2026-72349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt() On links faster than ~34 Gbps, where byte rate may exceed 2^32-1 (~ 4.3 GBps), the comparison result becomes incorrect because the truncated value no longer reflects the actual estimator rate. Fix by changing the local variables to u64.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72350", "url": "https://ubuntu.com/security/CVE-2026-72350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_u32: reject invalid shift counts u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation. Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64547", "url": "https://ubuntu.com/security/CVE-2026-64547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: net1080: validate packet_len before pad-byte access in rx_fixup For an even packet_len, net1080_rx_fixup() reads the pad byte at skb->data[packet_len] before the skb->len != packet_len check further down, and packet_len is only bounded against NC_MAX_PACKET. A malicious NetChip 1080 device can send a short frame advertising a large even packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the skb: BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14 ... net1080_rx_fixup (drivers/net/usb/net1080.c:384) usbnet_bh (drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3708) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) ... Reject the frame when packet_len >= skb->len before reading.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72371", "url": "https://ubuntu.com/security/CVE-2026-72371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the volume AFS_VOLUME_RM_TREE is set on Fix afs_insert_volume_into_cell() to set AFS_VOLUME_RM_TREE on the volume replaced, not the new volume, as it's now removed from the cell's volume tree. This will cause the old volume to be removed from the tree twice and the new volume never to be removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72374", "url": "https://ubuntu.com/security/CVE-2026-72374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix callback service message parsers to pass through -EAGAIN The AFS filesystem client uses an rxrpc server to listen for callback notifications. Each callback call type handler has a delivery function that parses the incoming request stream, and this should return -EAGAIN the last packet hasn't yet been seen, but all currently queued received data is consumed. afs_extract_data() does this, but the -EAGAIN return is switched to 0 inadvertantly Fix callback service message parsers to pass through -EAGAIN", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72378", "url": "https://ubuntu.com/security/CVE-2026-72378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix error code in afs_extract_vl_addrs() The error codes on these paths are only set on the first iteration through the loop. Set the correct error code on every iteration.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72389", "url": "https://ubuntu.com/security/CVE-2026-72389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: stp: Fix a potential use-after-free when deleting a bridge The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them. This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted. Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted. [1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64540", "url": "https://ubuntu.com/security/CVE-2026-64540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup() genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received. A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes. \tskb_put_data(gl_skb, packet->packet_data, size); then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up. BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72392", "url": "https://ubuntu.com/security/CVE-2026-72392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72396", "url": "https://ubuntu.com/security/CVE-2026-72396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: adm1275: Prevent reading uninitialized stack While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret < 0) { ... } for (mid = adm1275_id; mid->name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like \"adm12\", checking it against \"adm1275\" up to the length of \"adm1275\" will continue reading into uninitialized stack bounds. Prevent reading uninitialized memory by zeroing the stack array.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72400", "url": "https://ubuntu.com/security/CVE-2026-72400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: validate SRH length before reading fixed fields seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields. The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer. Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72406", "url": "https://ubuntu.com/security/CVE-2026-72406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sungem: fix probe error cleanup gem_init_one() calls gem_remove_one() when register_netdev() fails. gem_remove_one() unregisters and frees resources owned by the net_device, including the DMA block, MMIO mapping, PCI regions, and the net_device itself. gem_init_one() then falls through to its own cleanup labels and frees the same resources again. Keep the register_netdev() error path in gem_init_one(): clear drvdata so PM/remove paths do not see a half-registered device, remove the NAPI instance added during probe, and let the existing cleanup labels release the resources once. The issue was found by a local static-analysis checker for probe error paths. The reported path was manually inspected before sending this fix. Compile-tested with CONFIG_SUNGEM=y. Runtime testing was not performed because no sungem hardware is available.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72409", "url": "https://ubuntu.com/security/CVE-2026-72409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvneta: re-enable percpu interrupt on resume On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules NAPI poll, which calls enable_percpu_irq() on completion to unmask. If suspend occurs while NAPI poll is pending (between disable_percpu_irq in the ISR and enable_percpu_irq in poll completion), the interrupt is never re-enabled: 1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule() => MPIC masked, percpu_enabled cpumask bit cleared 2. NAPI poll does not complete before suspend proceeds (on PREEMPT_RT this is highly likely since softirqs run in ksoftirqd which gets frozen; on non-RT it can happen when softirq processing is deferred to ksoftirqd) 3. mvneta_stop_dev => napi_disable(): cancels the pending poll without executing the completion path 4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC (already masked, but records IRQS_SUSPENDED) 5. Resume: mpic_resume checks irq_percpu_is_enabled() => false (bit was cleared in step 1) => skips unmask 6. mvneta_start_dev only restores device-level INTR_NEW_MASK, does not touch the MPIC per-CPU mask Result: MPIC per-CPU interrupt stays masked permanently. The NIC generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never receives them, causing complete loss of network connectivity. Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path to unconditionally unmask the MPIC per-CPU interrupt regardless of pre-suspend state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72414", "url": "https://ubuntu.com/security/CVE-2026-72414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: round up PTP perout pin duration pin_duration is converted from the user-provided period to SJA1105 clock ticks and is later passed as the cycle_time argument to future_base_time(). Very small period values may become zero after the conversion, which can lead to a division by zero in future_base_time(). Round zero pin_duration up to 1 tick so that the smallest unsupported periods use the minimum non-zero hardware duration instead of passing zero to future_base_time().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64545", "url": "https://ubuntu.com/security/CVE-2026-64545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net, bpf: check master for NULL in xdp_master_redirect() xdp_master_redirect() dereferences the result of netdev_master_upper_dev_get_rcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency. The reach guard only checks netif_is_bond_slave(). On bond slave release bond_upper_dev_unlink() drops the upper-master adjacency before clearing IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window still passes netif_is_bond_slave() while master is already NULL, and faults on master->flags at offset 0xb0: BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdp_master_redirect (net/core/filter.c:4432) Call Trace: xdp_master_redirect (net/core/filter.c:4432) bpf_prog_run_generic_xdp (include/net/xdp.h:700) do_xdp_generic (net/core/dev.c:5608) __netif_receive_skb_one_core (net/core/dev.c:6204) process_backlog (net/core/dev.c:6319) __napi_poll (net/core/dev.c:7729) net_rx_action (net/core/dev.c:7792) handle_softirqs (kernel/softirq.c:622) __dev_queue_xmit (include/linux/bottom_half.h:33) packet_sendmsg (net/packet/af_packet.c:3082) __sys_sendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt The missing check dates back to the original code; commit 1921f91298d1 (\"net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master\") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72418", "url": "https://ubuntu.com/security/CVE-2026-72418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: prevent connlimit drops for early confirmed ct Commit 69894e5b4c5e (\"netfilter: nft_connlimit: update the count if add was skipped\") introduced a regression where packets for valid connections are dropped when using connlimit for soft-limiting scenarios. The issue occurs when a new connection reuses a socket currently in the TIME_WAIT state. In this scenario, the connection tracking entry is evaluated as already confirmed. Previously, __nf_conncount_add() assumed that if a connection was confirmed and did not originate from the loopback interface, it should skip the addition and return -EEXIST. Skipping the addition triggers a garbage collection run that cleans up the TIME_WAIT connection. Consequently, the active connection count drops to 0, which xt_connlimit mishandles, leading to the false rejection of the perfectly valid new connection. Fix this by replacing the interface check with protocol-agnostic state checks. We now skip the tree insertion and preserve the lockless garbage collection optimization only if the connection is IPS_ASSURED. This allows early-confirmed setup packets (such as reused TIME_WAIT sockets or locally generated SYN-ACKs) to be properly evaluated and counted without falsely dropping. The goto check_connections path is maintained to ensure these setup packets are deduplicated correctly. This has been tested with slowhttptest and HTTP server configured locally to ensure we are not breaking soft-limiting scenarios for local or external connections. In addition, it was tested with a OVS zone limit too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72421", "url": "https://ubuntu.com/security/CVE-2026-72421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't ignore error route in local/main tables. When CONFIG_IP_MULTIPLE_TABLES is enabled but no rule is added, fib_lookup() performs route lookup directly on two tables. Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table: # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache Once a random rule is added, the error route is respected: # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host Let's fix the inconsistent behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64538", "url": "https://ubuntu.com/security/CVE-2026-64538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix null-ptr-deref in fib6_nh_mtu_change(). fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown() clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(), but this re-fetch is unguarded; nexthop-backed routes survive addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is nulled. Return 0 when idev is NULL, matching rt6_mtu_change_route() and the fib6_mtu() fix in commit 5ad509c1fdad (\"ipv6: Fix null-ptr-deref in fib6_mtu().\"). Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6_nh_mtu_change+0x203/0x990 rt6_mtu_change_route+0x141/0x1d0 __fib6_clean_all+0xd0/0x160 rt6_mtu_change+0xb4/0x100 ndisc_router_discovery+0x24b5/0x2cb0 icmpv6_rcv+0x12e9/0x1710 ipv6_rcv+0x39b/0x410", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64546", "url": "https://ubuntu.com/security/CVE-2026-64546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72428", "url": "https://ubuntu.com/security/CVE-2026-72428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack slot index in nospec checks check_stack_write_fixed_off() computes the byte slot for a fixed-offset stack write as -off - 1, and records each written byte in slot_type[] with (slot - i) % BPF_REG_SIZE. The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a 4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates bytes 7..4. That can leave the second half-slot write without nospec_result even though the bytes being overwritten still require sanitization. Use the same slot index in the sanitization pre-check that the write path uses when updating slot_type[].", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72433", "url": "https://ubuntu.com/security/CVE-2026-72433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak This needs to test for nonzero retval.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72435", "url": "https://ubuntu.com/security/CVE-2026-72435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer() Sashiko pointed out that kfree_rcu() was called before rcu_assign_pointer() in handling the comment extension. Fix the order so that rcu_assign_pointer() called first.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72441", "url": "https://ubuntu.com/security/CVE-2026-72441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: fix kernel-infoleak in dgram_recvmsg() KMSAN reported a kernel-infoleak in move_addr_to_user(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925 ... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739 The issue occurs because the `pan_id` field of `struct ieee802154_addr` is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`. The execution flow is as follows: 1. `__ieee802154_rx_handle_packet()` declares a local `struct ieee802154_hdr hdr` on the stack. 2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse the source and destination addresses into this structure. 3. If the address mode is `IEEE802154_ADDR_NONE`, `ieee802154_hdr_get_addr()` previously only set the `mode` field, leaving the `pan_id` field containing uninitialized stack memory. 4. This uninitialized `pan_id` is later copied into a `struct sockaddr_ieee802154` in `dgram_recvmsg()` via `ieee802154_addr_to_sa()`. 5. Finally, `move_addr_to_user()` copies the socket address structure to user space, leaking the uninitialized bytes. Fix this by using `memset` to zero out the address structure in `ieee802154_hdr_get_addr()` when the mode is `IEEE802154_ADDR_NONE`.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72447", "url": "https://ubuntu.com/security/CVE-2026-72447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: hold socket lock when dumping endpoints in sctp_diag SCTP_DIAG endpoint dumping was traversing endpoint address lists without holding lock_sock(), while those lists could change concurrently via socket operations (e.g., bindx changes). This creates a race where nla_reserve() counts addresses under RCU protection, but the subsequent copy may see fewer entries, potentially leaking uninitialized memory to userspace. Fix this by: - Taking a reference on each endpoint during hash traversal - Moving socket operations (lock_sock()) outside read_lock_bh() - Serializing address list access during dump - Reworking sctp_for_each_endpoint() to support restart-based traversal with (net, pos) tracking Also: - Add WARN_ON_ONCE() for inconsistent address counts - Fix idiag_states filtering for LISTEN vs association cases - Skip dumping endpoints being freed (ep->base.dead) - Move dump position tracking into iterator, removing cb->args[4] and its comment for sctp_ep_dump()., - Update the comment for cb->args[4] and remove the comment for unused cb->args[5] for sctp_sock_dump(). Note: traversal is restart-based and may re-scan buckets multiple times, but this is acceptable due to small bucket sizes and required to support sleeping-safe callbacks. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64553", "url": "https://ubuntu.com/security/CVE-2026-64553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: psample: fix info leak in PSAMPLE_ATTR_DATA psample open codes nla_put() presumably to avoid wiping the data with 0s just to override it with packet data. This open coding is missing clearing the pad, however, each netlink attr is padded to 4B and data_len may not be divisible by 4B.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72448", "url": "https://ubuntu.com/security/CVE-2026-72448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix leak of SQ timestamp buffer on teardown The send-queue timestamp ring is allocated with qmem_alloc() when timestamping is used, but otx2_free_sq_res() never freed sq->timestamps, leaking that memory across ifdown and device removal. Add the missing qmem_free() alongside the other SQ companion buffers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72450", "url": "https://ubuntu.com/security/CVE-2026-72450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate selector family and prefixlen during match syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72459", "url": "https://ubuntu.com/security/CVE-2026-72459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: aa_label_alloc use aa_label_free on alloc failure aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init(). Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72460", "url": "https://ubuntu.com/security/CVE-2026-72460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72476", "url": "https://ubuntu.com/security/CVE-2026-72476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix possible use after free In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72479", "url": "https://ubuntu.com/security/CVE-2026-72479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: mma8452: handle I2C read error(s) in mma8452_read() Currently, If i2c_smbus_read_i2c_block_data() fails but mma8452_set_runtime_pm_state() succeeds, mma8452_read() returns 0. As a result, the caller mma8452_read_raw() assumes the read was successful and proceeds to use a buffer containing uninitialized stack memory. Add proper checking of the I2C read return value and propagate errors to the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72481", "url": "https://ubuntu.com/security/CVE-2026-72481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: ak8975: fix potential kernel stack memory leak Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72483", "url": "https://ubuntu.com/security/CVE-2026-72483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72484", "url": "https://ubuntu.com/security/CVE-2026-72484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: video: avoid double free on video register failure comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72489", "url": "https://ubuntu.com/security/CVE-2026-72489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: nvec: fix use-after-free in nvec_rx_completed() In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72492", "url": "https://ubuntu.com/security/CVE-2026-72492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in same_client_has_lease() same_client_has_lease() returns an opinfo pointer from ci->m_op_list after dropping ci->m_lock without taking a reference. smb_grant_oplock() then dereferences that pointer in copy_lease() and when checking breaking_cnt. A concurrent close can remove the old lease from ci->m_op_list and drop the last reference before the caller uses the returned pointer, leading to a use-after-free. Take a reference when same_client_has_lease() selects an existing lease, drop any previous match while scanning, and release the returned reference in smb_grant_oplock() after copying the lease state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72502", "url": "https://ubuntu.com/security/CVE-2026-72502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF) When MTU is large, ip6_default_advmss() can return IPV6_MAXPLEN (65535). This is interpreted by TCP as mss_clamp, allowing the MSS to reach 65535. However, 0xFFFF is also used as a magic value GSO_BY_FRAGS in the kernel. If a TCP packet with gso_size=0xFFFF is passed to skb_segment(), it will be mistakenly treated as GSO_BY_FRAGS, leading to a NULL pointer dereference because local TCP packets do not use frag_list. Fix this by returning min(IPV6_MAXPLEN, GSO_BY_FRAGS - 1) (65534) from ip6_default_advmss() when MTU is large. Also update the stale comment in ip6_default_advmss() which suggested that IPV6_MAXPLEN is returned to mean \"any MSS\".", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74256", "url": "https://ubuntu.com/security/CVE-2026-74256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check start and len are u32, so \tu64 last = start + len; evaluates start + len in 32-bit and wraps before storing it in last. The bounds check \tif (start >= offset + l || last > msg->sg.size) \t\treturn -EINVAL; can then be passed with an out-of-range start/len, after which the pop loop runs off the end of the scatterlist and sk_msg_shift_left() calls put_page() on the empty msg->sg.end slot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:sk_msg_shift_left net/core/filter.c:2957 [inline] RIP: 0010:____bpf_msg_pop_data net/core/filter.c:3103 [inline] RIP: 0010:bpf_msg_pop_data+0x753/0x1a10 net/core/filter.c:2984 Call Trace: bpf_prog_4cc92c278f4d5d56+0x1b1/0x1e8 bpf_prog_run_pin_on_cpu+0x107/0x320 include/linux/filter.h:746 sk_psock_msg_verdict+0x357/0x7f0 net/core/skmsg.c:934 tcp_bpf_send_verdict net/ipv4/tcp_bpf.c:420 [inline] tcp_bpf_sendmsg+0x766/0x1ae0 net/ipv4/tcp_bpf.c:583 __sock_sendmsg+0x153/0x1c0 net/socket.c:802 __sys_sendto+0x326/0x430 net/socket.c:2265 __x64_sys_sendto+0xe3/0x100 net/socket.c:2268 do_syscall_64+0x14c/0x480 entry_SYSCALL_64_after_hwframe+0x77/0x7f Widen the addition with a (u64) cast so the bound is evaluated in 64-bit and a len near U32_MAX no longer wraps below msg->sg.size. While here, change pop from int to u32. It counts bytes against the unsigned scatterlist lengths and can never be negative, so the signed type only invites sign-confusion in the pop loop.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64548", "url": "https://ubuntu.com/security/CVE-2026-64548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data() When the scatterlist ring is full or nearly full, bpf_msg_push_data() enters a copy fallback path and computes copy + len for the page allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING and both are u32, a crafted len can wrap the sum to a small value, causing an undersized allocation followed by an out-of-bounds memcpy. BUG: unable to handle page fault for address: ffffed104089a402 Oops: Oops: 0000 [#1] SMP KASAN NOPTI Call Trace: __asan_memcpy (mm/kasan/shadow.c:105) bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) bpf_prog_9ed8b5711920a7d7+0x2e/0x36 sk_psock_msg_verdict (net/core/skmsg.c:934) tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) __sys_sendto (net/socket.c:2206) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add an overflow check before the allocation.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74262", "url": "https://ubuntu.com/security/CVE-2026-74262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcm: use WRITE_ONCE() when changing lower socket callbacks kcm_attach() replaces a live lower TCP socket's sk_data_ready and sk_write_space callbacks with KCM handlers, and kcm_unattach() restores them later. Those callback-pointer updates are still plain stores even though the same fields can be read and invoked concurrently on other CPUs. If another CPU observes an older callback snapshot after the live field has already been restored, callback execution can run with a mismatched target and sk_user_data state, leading to stale or misdirected wakeups. Use WRITE_ONCE() for the callback replacement and restore operations so these shared callback fields follow the same visibility contract already established by the earlier 4022 fixes.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74265", "url": "https://ubuntu.com/security/CVE-2026-74265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: initialize gdma queue id to INVALID_QUEUE_ID mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74276", "url": "https://ubuntu.com/security/CVE-2026-74276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: xilinx: use FIFO occupancy register to determine buffer size The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. When a SPI transaction wants to write the amount of the FIFO size or more bytes, the following happens, for example with 16 bytes FIFO size: The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and starts the SPI hardware and goes sleep. The hardware then shifts out 17 bytes (FIFO + shift register) and simultaneously reads bytes into the RX FIFO, but it only has 16 places, so it looses one byte. Then TX FIFO empty asserts, wakes the driver again, which has a fast path and reads 16 bytes from the RX FIFO, but before reading the last 17th byte (which is lost) it does this: \tsr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); \tif (!(sr & XSPI_SR_RX_EMPTY_MASK)) { \t\txilinx_spi_rx(xspi); \t\trx_words--; \t} It reads the status register and checks if the RX FIFO is not empty. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74279", "url": "https://ubuntu.com/security/CVE-2026-74279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: cavium/cpt - fix DMA cleanup using wrong loop index The sg_cleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74280", "url": "https://ubuntu.com/security/CVE-2026-74280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/octeontx - fix DMA cleanup using wrong loop index The sg_cleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74281", "url": "https://ubuntu.com/security/CVE-2026-74281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74282", "url": "https://ubuntu.com/security/CVE-2026-74282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: prevent snt_unacked underflow on CONN_ACK tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: \ttsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74283", "url": "https://ubuntu.com/security/CVE-2026-74283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74284", "url": "https://ubuntu.com/security/CVE-2026-74284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: Don't make class passive twice update_vf() is called from two places for the same class during a single dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last packets while dequeuing: 1. The child calls qdisc_tree_reduce_backlog(), which, now that the child is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns the class passive (cl_nactive is decremented up the hierarchy). 2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time) to charge the dequeued bytes. On the second call the class is already passive, but its child qdisc is still empty, so update_vf() arms go_passive again: if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1; The leaf is then skipped by the cl_nactive == 0 check inside the loop, which does not clear go_passive, so the stale go_passive propagates to the parent and decrements its cl_nactive a second time. A parent that still has other active children is driven to cl_nactive == 0 and removed from the vttree, even though those siblings are still backlogged. They are never dequeued again and the qdisc stalls. Fix this by only arming go_passive when the class is actually active, so an already-passive class no longer triggers a second passive transition. The byte accounting (cl->cl_total += len) still runs for every ancestor, so dequeued bytes continue to be counted exactly once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64537", "url": "https://ubuntu.com/security/CVE-2026-64537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: reject invalid CCM interval at configuration time ccm_tx_work_expired() re-arms itself via queue_delayed_work() using the configured exp_interval converted by interval_to_us(). When exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range, interval_to_us() returns 0, causing the worker to fire immediately in a tight loop that allocates skbs until OOM. Fix this by validating exp_interval at configuration time: - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the netlink policy so userspace cannot set an invalid value. - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not yet been configured (defaults to 0 from kzalloc).", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74288", "url": "https://ubuntu.com/security/CVE-2026-74288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fib_rules: Don't dump dying fib_rule in fib_rules_dump(). rocker_router_fib_event() calls fib_rule_get() during RCU dump. If the fib_rule is dying, refcount_inc() will complain about it. Let's call refcount_inc_not_zero() in fib_rules_dump().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74292", "url": "https://ubuntu.com/security/CVE-2026-74292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tegra: tegra210_ahub: Validate written enum value tegra_ahub_put_value_enum() reads e->values[item[0]] before checking whether item[0] is within the enum item range. The existing check therefore happens too late to prevent an out-of-range read of the values array. Move the check before the array access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74293", "url": "https://ubuntu.com/security/CVE-2026-74293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: fsl_audmix: Validate written enum values fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src() convert the user-provided enum item with snd_soc_enum_item_to_val() before checking whether the item is within the enum's item count. The generic snd_soc_put_enum_double() helper performs that validation, but these callbacks use the converted value first: the clock-source path tests it with BIT(), and the output-source path indexes the prms transition table with it. Reject out-of-range enum items before converting them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74295", "url": "https://ubuntu.com/security/CVE-2026-74295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: hdac_hdmi: Validate written enum value hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range. An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74297", "url": "https://ubuntu.com/security/CVE-2026-74297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix undefined shift of user RQ WQE size set_rq_size() computes the RQ WQE size as \"1 << rq_wqe_shift\" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74305", "url": "https://ubuntu.com/security/CVE-2026-74305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tighten cgroup storage cookie checks for prog arrays The fix in commit abad3d0bad72 (\"bpf: Fix oob access in cgroup local storage\") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74312", "url": "https://ubuntu.com/security/CVE-2026-74312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: validate virtqueue index in mmap and fault paths vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74313", "url": "https://ubuntu.com/security/CVE-2026-74313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: hold vduse_lock across IDR lookup in open path vduse_dev_open() looks up struct vduse_dev through the IDR and then acquires dev->lock only after vduse_lock has been dropped. This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the same object from the IDR and free it before the open path locks the device, leading to a use-after-free. Close this race by keeping vduse_lock held until dev->lock has been acquired in the open path, matching the lock ordering already used by the destroy path.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74320", "url": "https://ubuntu.com/security/CVE-2026-74320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, \"mode\", &len) is just written over either the static \"640x480-16@60\" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74321", "url": "https://ubuntu.com/security/CVE-2026-74321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 (\"btrfs: refactor __btrfs_run_delayed_refs loop\") but were unintentionally lost afterwards.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74327", "url": "https://ubuntu.com/security/CVE-2026-74327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmalloc: fix NULL pointer dereference in is_vm_area_hugepages() find_vm_area() can return NULL if the given address is not a valid vmalloc area. Check the return value before dereferencing it to avoid a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74329", "url": "https://ubuntu.com/security/CVE-2026-74329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: unregister PM notifier on watchdog unregister watchdog_register_device() registers wdd->pm_nb when WDOG_NO_PING_ON_SUSPEND is set, but watchdog_unregister_device() does not remove it. This leaves an embedded notifier block on the PM notifier chain after the watchdog device has been unregistered. A later suspend/resume notification can then call watchdog_pm_notifier() with a stale watchdog_device pointer, or at minimum after wdd->wd_data has been cleared by watchdog_dev_unregister(). Unregister the PM notifier before tearing down the watchdog device.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74330", "url": "https://ubuntu.com/security/CVE-2026-74330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: fix lockless traversals of ->s_children Having the parent directory locked protects entries from removal by another thread, but it does *not* protect cursors from being moved around by lseek() - or freed, for that matter.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74331", "url": "https://ubuntu.com/security/CVE-2026-74331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix recursive lock in device_cache_fw_images() A recursive locking deadlock can occur in the firmware loader's power management notification handler. During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock. For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread. The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock. Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74339", "url": "https://ubuntu.com/security/CVE-2026-74339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Clear variable event pointer on read snd_seq_read() copies a queued variable-length event header to userspace before expanding the payload. Queued variable-length events use SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first extension cell. The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the copy, but it leaves data.ext.ptr untouched. A userspace sequencer client can therefore write a direct variable event to itself and read back the extension-cell kernel address from the returned header. Clear the temporary header pointer before copy_to_user(). The original queued event remains unchanged and is still passed to snd_seq_expand_var_event(), so payload expansion keeps using the internal chain.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74340", "url": "https://ubuntu.com/security/CVE-2026-74340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74346", "url": "https://ubuntu.com/security/CVE-2026-74346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74348", "url": "https://ubuntu.com/security/CVE-2026-74348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: require a ref for locking_state debugfs open debug_lockres_open() copies inode->i_private into struct debug_lockres and debug_lockres_release() later drops that pointer with dlm_put(). That only works if open successfully pins the struct dlm_ctxt. Today open calls dlm_grab(dlm) but ignores its return value. Once the last domain unregister has removed the context from dlm_domains, dlm_grab() returns NULL, yet open still stores the raw pointer and returns success. The later release path is outside the debugfs removal barrier, so it can call dlm_put() after dlm_free_ctxt_mem() has freed the context. KASAN reports this as a slab-use-after-free in dlm_put() called from debug_lockres_release(). Fail the open when dlm_grab() cannot acquire the reference and unwind the seq_file private state before returning. That keeps locking_state from handing out a file descriptor whose release path does not own the dlm_ctxt. The buggy scenario involves two paths, with each column showing the order within that path: locking_state debugfs open: last domain unregister: 1. debug_lockres_open() reads 1. dlm_unregister_domain() calls inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() calls 2. shutdown removes the dlm_ctxt from dlm_grab(dlm) and gets NULL. dlm_domains. 3. open still stores the raw dlm 3. final teardown reaches pointer in dl->dl_ctxt and dlm_free_ctxt_mem() and frees it. returns success. 4. debug_lockres_release() later calls dlm_put(dl->dl_ctxt). Validation reproduced this kernel report: KASAN slab-use-after-free in dlm_put+0x82/0x200 RIP: 0033:0x7f4d349bc9e0 The buggy address belongs to the object at ffff888103a3c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 816 bytes inside of freed 2048-byte region [ffff888103a3c000, ffff888103a3c800) Write of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) dlm_put+0x82/0x200 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) kasan_check_range+0x105/0x1b0 (?:?) debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) dlm_put+0x9/0x200 (?:?) debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) full_proxy_release+0x67/0x90 (?:?) __fput+0x1df/0x4b0 (?:?) do_raw_spin_lock+0x10f/0x1b0 (?:?) fput_close_sync+0xd2/0x170 (?:?) __x64_sys_close+0x55/0x90 (?:?) do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87) irqentry_exit+0xac/0x6e0 (?:?) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Freed by task stack: kasan_save_stack+0x33/0x60 (?:?) kasan_save_track+0x14/0x30 (?:?) kasan_save_free_info+0x3b/0x60 (?:?) __kasan_slab_free+0x5f/0x80 (?:?) kfree+0x30f/0x580 (?:?) dlm_put+0x1ce/0x200 (?:?) dlm_unregister_domain+0xf6/0xb30 (?:?) o2cb_cluster_disconnect+0x6b/0x90 (?:?) ocfs2_cluster_disconnect+0x41/0x70 (?:?) ocfs2_dlm_shutdown+0x1c4/0x220 (?:?) ocfs2_dismount_volume+0x38a/0x550 (?:?) generic_shutdown_super+0xc3/0x220 (?:?) kill_block_super+0x29/0x60 (?:?) deactivate_locked_super+0x66/0xe0 (?:?) cleanup_mnt+0x13d/0x210 (?:?) task_work_run+0xfa/0x170 (?:?) exit_to_user_mode_loop+0xd6/0x430 (?:?) do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74349", "url": "https://ubuntu.com/security/CVE-2026-74349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject FITRIM ranges shorter than a cluster ocfs2_trim_mainbm() trims the global bitmap in cluster units, but its too-short range validation only checks sb->s_blocksize. On filesystems with a cluster size larger than the block size, a FITRIM range that is at least one block but shorter than one cluster is accepted and shifted down to len == 0. The later start + len - 1 and len -= ... arithmetic then underflows and can drive trimming past the requested range. Reject ranges shorter than s_clustersize instead. That preserves the existing -EINVAL behavior for requests that cannot discard even one allocation unit and keeps zero-cluster trims out of the group walk.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74351", "url": "https://ubuntu.com/security/CVE-2026-74351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74359", "url": "https://ubuntu.com/security/CVE-2026-74359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs_lookup(): don't leave ->s_dentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74363", "url": "https://ubuntu.com/security/CVE-2026-74363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs commit 4f375ade6aa9 (\"bpf: Avoid RCU context warning when unpinning htab with internal structs\") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.). This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime(). KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags) The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74379", "url": "https://ubuntu.com/security/CVE-2026-74379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax/kmem: account for partial discontiguous resource upon removal When dev_dax_kmem_probe() partially succeeds (at least one range is mapped) but a subsequent range fails request_mem_region() or add_memory_driver_managed(), the probe silently continues, ultimately returning success, but with the corresponding range resource NULL'ed out. dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the underlying resource exists. When remove_memory() is called later, it returns 0 because the memory was never added which causes dev_dax_kmem_remove() to incorrectly assume the (nonexistent) resource can be removed and attempts cleanup on a NULL pointer. Fix this by skipping these ranges altogether, noting that these cases are considered success, such that the cleanup is still reached when all actually-added ranges are successfully removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74382", "url": "https://ubuntu.com/security/CVE-2026-74382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74390", "url": "https://ubuntu.com/security/CVE-2026-74390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr->pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don't overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74395", "url": "https://ubuntu.com/security/CVE-2026-74395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list before initializing the fields used by the shared error path. If eventfd_ctx_fdget() then fails, the unwind path dereferences event_sub->ev_file in uverbs_uobject_put() and calls subscribe_event_xa_dealloc() with an unset xa_key_level1. subscribe_event_xa_alloc() creates the XA entry exactly once for a given key_level1, on the first occurrence of that key. The unwind path must therefore call subscribe_event_xa_dealloc() exactly once for it as well. Enforce that by adding devx_key_in_sub_list() and calling subscribe_event_xa_dealloc() only when the last matching pending entry is being cleaned up.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74399", "url": "https://ubuntu.com/security/CVE-2026-74399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64544", "url": "https://ubuntu.com/security/CVE-2026-64544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents pefile_digest_pe_contents() computes the trailing-data hash length as pelen - (hashed_bytes + certs_size). A crafted PE can make the addition exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB. This is passed to crypto_shash_update() which reads out of bounds and panics on unmapped vmalloc guard pages. BUG: unable to handle page fault for address: ffffc900038d8000 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152) Call Trace: __sha256_update (lib/crypto/sha256.c:208) crypto_sha256_update (crypto/sha256.c:142) verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436) kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151) __do_sys_kexec_file_load (kernel/kexec_file.c:406) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Validate that the addition does not overflow and the result does not exceed pelen before the subtraction. Return -ELIBBAD on failure.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74402", "url": "https://ubuntu.com/security/CVE-2026-74402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix blocking and non-blocking rng logic The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74408", "url": "https://ubuntu.com/security/CVE-2026-74408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: fix OOB access from firmware tx status queue ID ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74410", "url": "https://ubuntu.com/security/CVE-2026-74410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478), causing an out-of-bounds read from the pre-allocated DMA buffer when skb_put_data copies new_len bytes. The USB transport already validates this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the PCIe path does not. Add a check that new_len does not exceed the DMA buffer size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74416", "url": "https://ubuntu.com/security/CVE-2026-74416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix memory leak in radeon_ring_restore() on lock failure radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74424", "url": "https://ubuntu.com/security/CVE-2026-74424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix NULL pointer dereference for a console without vc_data fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data. Keep fb_display[i].mode set only while the console has a vc_data. Check vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74426", "url": "https://ubuntu.com/security/CVE-2026-74426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: fix NULL pointer dereference in afs_get_tree() afs_alloc_sbi() uses kzalloc for memory allocation. And, if ctx->dyn_root is not null, as->cell and as->volume are null. In trace_afs_get_tree() they are dereferenced. KASAN error message: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550 include/trace/events/afs.h:1365 Call Trace: trace_afs_get_tree include/trace/events/afs.h:1365 [inline] afs_get_tree+0x922/0x1350 fs/afs/super.c:599 vfs_get_tree+0x8e/0x300 fs/super.c:1572 do_new_mount fs/namespace.c:3011 [inline] path_mount+0x14a5/0x2220 fs/namespace.c:3341 do_mount fs/namespace.c:3354 [inline] __do_sys_mount fs/namespace.c:3562 [inline] __se_sys_mount fs/namespace.c:3539 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3539 do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74438", "url": "https://ubuntu.com/security/CVE-2026-74438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun4i-ss - Remove insecure and unused rng_alg Remove sun4i_ss_rng, as it is insecure and unused: - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing locking and has a buffer overflow. sun4i_ss_prng_generate() fails to fill the entire buffer with cryptographic random bytes, because it rounds the destination length down and also doesn't actually wait for the hardware to be ready before pulling bytes from it. - No user of this code is known. It's usable only theoretically via the \"rng\" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen and discovered by Atuin - Automated Vulnerability Discovery Engine There's no point in fixing all these vulnerabilities individually when this is unused code, so let's just remove it.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74578", "url": "https://ubuntu.com/security/CVE-2026-74578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_skcipher - force synchronous processing on trees without ctx->state The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx->iv directly into the skcipher request. After io_submit() the socket lock is dropped and the request is processed asynchronously, so a concurrent sendmsg(ALG_SET_IV) can overwrite ctx->iv and make the in-flight request run under an attacker-controlled IV. For CTR/stream modes this is IV/keystream reuse and lets an unprivileged user recover the plaintext of a concurrent operation. Snapshotting ctx->iv into per-request storage for the async path is not sufficient. For ciphers with statesize == 0 - which includes cbc and ctr - the MSG_MORE inter-chunk IV chaining is carried solely by the in-place req->iv writeback, which a snapshot redirects into per-request memory that af_alg_free_resources() releases on completion, silently producing wrong output. Writing the IV back from the completion callback instead is not possible either: that would require lock_sock() there, but the callback can run in softirq/atomic context, so it must not sleep. Make the operation synchronous instead, which removes both the IV race and any writeback race. This is equivalent to the upstream resolution, commit fcc77d33a34c (\"net: Remove support for AIO on sockets\"), which removed the AIO socket path across net/ entirely and so produces the same end state for this file. This patch deviates from that commit deliberately: rather than removing AIO socket support tree-wide, which would be far too invasive for stable, it removes only the AIO branch in crypto/algif_skcipher.c. io_submit() now completes synchronously; AF_ALG async is rarely used in practice. The -EIOCBQUEUED check in skcipher_recvmsg() is now dead but harmless, and is left alone to keep the fix minimal. Tested on 6.6.y: attacker IV injection dropped from 2296/200000 to 0/200000 after the change; MSG_MORE chunked CTR output bit-identical to single-shot.", "cve_priority": "medium", "cve_public_date": "2026-08-16 09:16:00 UTC" }, { "cve": "CVE-2026-64600", "url": "https://ubuntu.com/security/CVE-2026-64600", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.", "cve_priority": "medium", "cve_public_date": "2026-07-23 06:16:00 UTC" }, { "cve": "CVE-2026-64187", "url": "https://ubuntu.com/security/CVE-2026-64187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fail recovery on a committed log item with no regions If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367)", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64266", "url": "https://ubuntu.com/security/CVE-2026-64266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before returning from fuse_ref_folio() fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues. Fix this by locking the request in fuse_ref_folio() before returning.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64268", "url": "https://ubuntu.com/security/CVE-2026-64268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64269", "url": "https://ubuntu.com/security/CVE-2026-64269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64271", "url": "https://ubuntu.com/security/CVE-2026-64271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: touchwin - reset the packet index on every complete packet tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: \ttw->data[tw->idx++] = data; \tif (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { \t\t... \t\ttw->idx = 0; \t} The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64273", "url": "https://ubuntu.com/security/CVE-2026-64273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - bound the device-reported force-feedback effect index iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: \ti = data[1] & 0x7f; \tif (data[1] & 0x80) { \t\tif (!test_and_set_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) \t\t\t... \t} else if (test_and_clear_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) { \t\t... \t} The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate \"effect started/stopped\" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64274", "url": "https://ubuntu.com/security/CVE-2026-64274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: goodix - clamp the device-reported contact count goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer \tu8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: \tts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64275", "url": "https://ubuntu.com/security/CVE-2026-64275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: elan_i2c - prevent division by zero and arithmetic underflow The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64276", "url": "https://ubuntu.com/security/CVE-2026-64276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64277", "url": "https://ubuntu.com/security/CVE-2026-64277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64279", "url": "https://ubuntu.com/security/CVE-2026-64279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter deregistration race Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name).", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64604", "url": "https://ubuntu.com/security/CVE-2026-64604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f No functional change intended.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64296", "url": "https://ubuntu.com/security/CVE-2026-64296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: \tif (++order == 2) \t\tuniname = p_uniname->name; \telse \t\tuniname += EXFAT_FILE_NAME_LEN; \tlen = exfat_extract_uni_name(ep, entry_uniname); \tname_len += len; \tunichar = *(uniname+len); \t*(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba (\"exfat: check if filename entries exceeds max filename length\")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64298", "url": "https://ubuntu.com/security/CVE-2026-64298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: include MAY_WRITE in open permission mask for O_TRUNC POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64299", "url": "https://ubuntu.com/security/CVE-2026-64299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64303", "url": "https://ubuntu.com/security/CVE-2026-64303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64306", "url": "https://ubuntu.com/security/CVE-2026-64306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: drbg - Fix returning success on failure in CTR_DRBG drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64312", "url": "https://ubuntu.com/security/CVE-2026-64312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64313", "url": "https://ubuntu.com/security/CVE-2026-64313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ecc - Fix carry overflow in vli multiplication The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows. The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow. When commit 3c4b23901a0c (\"crypto: ecdh - Add ECDH software support\") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation. Add proper handling for this boundary by accounting for the carry from the lower addition.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64315", "url": "https://ubuntu.com/security/CVE-2026-64315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64316", "url": "https://ubuntu.com/security/CVE-2026-64316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64317", "url": "https://ubuntu.com/security/CVE-2026-64317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge \"SL\" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64318", "url": "https://ubuntu.com/security/CVE-2026-64318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: aix: bound the pp_count scan to the ppe array aix_partition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array: \tint numpps = be16_to_cpu(pvd->pp_count); \t... \tfor (i = 0; i < numpps; i += 1) { \t\tstruct ppe *p = pvd->ppe + i; \t\t... \t\tlp_ix = be16_to_cpu(p->lp_ix); pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk pp_count. pp_count is an unvalidated __be16 read straight from the descriptor, so a crafted AIX image with pp_count larger than 1016 drives the loop to read pvd->ppe[i] past the end of the allocation (up to 65535 entries, ~2 MB out of bounds). The partition scan runs without mounting anything, when a block device with a crafted AIX/IBM partition table appears (an attacker-supplied image attached with losetup -P, or a device auto-scanned by udev), via msdos_partition() -> aix_partition(). Clamp the scan to the number of entries the ppe[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64322", "url": "https://ubuntu.com/security/CVE-2026-64322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when \tsizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: \tfor (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) { \t\tstruct sparingEntry *entry = &st->mapEntry[i]; \t\t... entry->origLocation ... \t} in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64323", "url": "https://ubuntu.com/security/CVE-2026-64323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate VAT header length against the VAT inode size udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size: \tmap->s_type_specific.s_virtual.s_start_offset = \t\tle16_to_cpu(vat20->lengthHeader); \tmap->s_type_specific.s_virtual.s_num_entries = \t\t(sbi->s_vat_inode->i_size - \t\t\tmap->s_type_specific.s_virtual.s_start_offset) >> 2; lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the \"block > s_num_entries\" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads \t((__le32 *)(iinfo->i_data + s_start_offset))[block] so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read. Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64324", "url": "https://ubuntu.com/security/CVE-2026-64324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate free block extents against the partition length udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64330", "url": "https://ubuntu.com/security/CVE-2026-64330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64331", "url": "https://ubuntu.com/security/CVE-2026-64331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running `usbip attach` from the host would cause the guest to oops with the following backtrace: Call trace: vep_dequeue+0x1c/0xe4 (P) usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34 __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64332", "url": "https://ubuntu.com/security/CVE-2026-64332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ulpi: fix memory leak on registration failure The allocated device name is never freed on early ULPI device registration failures. Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64333", "url": "https://ubuntu.com/security/CVE-2026-64333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64334", "url": "https://ubuntu.com/security/CVE-2026-64334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix hard lockup on disconnect If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled. Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect. This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64335", "url": "https://ubuntu.com/security/CVE-2026-64335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix broken rx after throttle If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound). Clear the throttle flags and submit the urb if needed when opening the port.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64336", "url": "https://ubuntu.com/security/CVE-2026-64336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan_pda: fix information leak The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspan_pda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer. Fix the information leak by making sure that keyspan_pda_write_start() returns zero on success as intended.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64337", "url": "https://ubuntu.com/security/CVE-2026-64337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: unmap request DMA on queue failure mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails. Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64338", "url": "https://ubuntu.com/security/CVE-2026-64338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: misc: uss720: unregister parport on probe failure uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered. Leaving the port registered is more than a private allocation leak: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is about to release. Undo the pre-announce registration in the get_1284_register() failure branch before jumping to the common private-data cleanup path. Clear priv->pp first, matching the disconnect path and avoiding a stale pointer in the private data. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64340", "url": "https://ubuntu.com/security/CVE-2026-64340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: legousbtower: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64342", "url": "https://ubuntu.com/security/CVE-2026-64342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: iowarrior: fix use-after-free on disconnect Submitted write URBs are not stopped on close() and therefore need to be stopped unconditionally on disconnect() to avoid use-after-free in the completion handler.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64343", "url": "https://ubuntu.com/security/CVE-2026-64343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ldusb: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64344", "url": "https://ubuntu.com/security/CVE-2026-64344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64346", "url": "https://ubuntu.com/security/CVE-2026-64346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: Fix use-after-free in gadget_match_driver The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usb_del_gadget() frees the udc memory (e.g., via mode-switch work) while gadget_match_driver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed: [39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr : gadget_match_driver+0x34/0x60 ... [39430.911890][ T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][ T1171] Workqueue: events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usb_gadget_release() routine to the core. When the gadget is added, usb_add_gadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usb_gadget_release() drops the reference to the udc and then calls the gadget's release routine.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64347", "url": "https://ubuntu.com/security/CVE-2026-64347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler The OTG branch of composite_setup() falls back to the first configuration when none is selected: \tif (cdev->config) \t\tconfig = cdev->config; \telse \t\tconfig = list_first_entry(&cdev->configs, \t\t\t\t\t struct usb_configuration, list); \tif (!config) \t\tgoto done; \t... \tmemcpy(req->buf, config->descriptors[0], value); list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the \"if (!config)\" check is dead. When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer. cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch. Use list_first_entry_or_null() so the existing check does its job.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64350", "url": "https://ubuntu.com/security/CVE-2026-64350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info() cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and stream_rings array, but leaves stream_ctx_array allocated. Free the stream context array before falling through to the stream_rings cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64351", "url": "https://ubuntu.com/security/CVE-2026-64351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: bound RX frame length in kalmia_rx_fixup() kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usb_packet_length to about 65530. That bypasses the usb_packet_length < ether_packet_length truncation path. The device-supplied ether_packet_length, a le16 up to 65535 read from header_start[2], then drives a memcmp() and the following skb_trim() and skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10, which is 14000 bytes. That is an out of bounds read. Require both the start and end framing headers to be present before subtracting them, on every loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64359", "url": "https://ubuntu.com/security/CVE-2026-64359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64360", "url": "https://ubuntu.com/security/CVE-2026-64360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64362", "url": "https://ubuntu.com/security/CVE-2026-64362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: lg-g15: cancel pending work on remove to fix a use-after-free lg_g15_data is allocated with devm and holds a work item. The report handlers schedule that work straight from device input. lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key, and lg_g510_leds_event() does it too. The worker dereferences the lg_g15_data back through container_of. The driver had no remove callback and never cancelled the work. So if a report scheduled the work and the keyboard was then unplugged, devres freed lg_g15_data while the work was still pending or running, and the worker touched freed memory. This is a use-after-free. It is reachable as a race on device unplug. Add a remove callback that cancels the work before devres frees the state. g15->work is only initialized for the models that schedule it (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the cancel on g15->work.func to avoid cancelling a work that was never set up. The g15 NULL test mirrors the one already in lg_g15_raw_event().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68091", "url": "https://ubuntu.com/security/CVE-2026-68091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: stop hardware after post-start probe failures wacom_parse_and_register() starts HID hardware before registering inputs and initializing pad LEDs/remotes. Those later steps can fail, but their error paths currently release Wacom resources without stopping the HID hardware. Route post-hid_hw_start() failures through hid_hw_stop() before releasing driver resources. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64370", "url": "https://ubuntu.com/security/CVE-2026-64370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference via get_pid() and stores it in timer.it.cpu.pid. If the subsequent posix_cpu_timer_set() call fails, the function returns immediately without calling posix_cpu_timer_del() to release the pid reference, causing a leak. Fix it by calling posix_cpu_timer_del() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64372", "url": "https://ubuntu.com/security/CVE-2026-64372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: pcc: fix use-after-free and double free in _OSC evaluation pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the two-phase _OSC negotiation. Between the two calls it freed output.pointer but left output.length unchanged. Since acpi_evaluate_object() treats a non-zero length with a non-NULL pointer as an existing buffer to write into, the second call wrote into freed memory (use-after-free). The subsequent kfree(output.pointer) at out_free then freed the same pointer a second time (double free). Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first result, so ACPICA allocates a fresh buffer for each phase independently.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64373", "url": "https://ubuntu.com/security/CVE-2026-64373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path. Unlike the normal system suspend path, the reboot path does not call freeze_processes(), so userspace processes and kernel threads remain active. This allows CPU hotplug operations to run concurrently with cpufreq_suspend(). The original code has no synchronization with CPU hotplug, leading to a race condition where governor_data can be freed by the hotplug path while cpufreq_suspend() is still accessing it, resulting in a null pointer dereference: Unable to handle kernel NULL pointer dereference Call Trace: do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200 Fix this by adding cpus_read_lock()/cpus_read_unlock() to cpufreq_suspend() to block CPU hotplug operations while suspend is in progress. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64374", "url": "https://ubuntu.com/security/CVE-2026-64374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64403", "url": "https://ubuntu.com/security/CVE-2026-64403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64408", "url": "https://ubuntu.com/security/CVE-2026-64408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: pin L2CAP connection during netdev registration bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64411", "url": "https://ubuntu.com/security/CVE-2026-64411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: terminate table name before find_table_lock() update_counters() and compat_update_counters() forward a user-supplied 32-byte table name to find_table_lock() without NUL-terminating it. On a lookup miss, find_inlist_lock() calls try_then_request_module(..., \"%s%s\", \"ebtable_\", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte. BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) __request_module (kernel/module/kmod.c:150) do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) update_counters (net/bridge/netfilter/ebtables.c:1440) do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573) nf_setsockopt (net/netfilter/nf_sockopt.c:101) ip_setsockopt (net/ipv4/ip_sockglue.c:1424) raw_setsockopt (net/ipv4/raw.c:847) __sys_setsockopt (net/socket.c:2393) ... compat_do_replace() shares the same unterminated name via compat_copy_ebt_replace_from_user(); terminate it there too so all find_table_lock() callers behave alike. The other callers already terminate the name after the copy.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64412", "url": "https://ubuntu.com/security/CVE-2026-64412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: module names must be null-terminated We need to explicitly check the length, else we may pass non-null terminated string to request_module().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64420", "url": "https://ubuntu.com/security/CVE-2026-64420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: cros_ec: Delay dev_set_drvdata() until probe success If ec_device_probe() fails, cros_ec_class_release releases memory for the cros_ec_dev structure. However, because the drvdata was already set, sub-drivers like cros_ec_typec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when cros_ec_typec attempts to access &typec->ec->ec->dev on a device that has already been released. Move dev_set_drvdata() to ensure that the pointer is only made available once all initialization steps have succeeded. sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' Call trace: sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... BUG: KASAN: invalid-access in __memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOT_MODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: events_unbound deferred_probe_work_func Call trace: __memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64422", "url": "https://ubuntu.com/security/CVE-2026-64422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP socket state. The sysctl is stored as an `int` but copied into the `u32` `tp->reordering` field for new sockets, so negative writes wrap to large values. With `tcp_mtu_probing=2`, the wrapped value can overflow the `tcp_mtu_probe()` size calculation and drive the MTU probing path into an out-of-bounds read. Route `tcp_reordering` writes through `proc_dointvec_minmax()` and require it to be at least 1. Also require `tcp_max_reordering` to be at least 1 so the configured maximum cannot become negative either. When registering the table for a non-init network namespace, relocate `extra2` pointers that refer into `init_net.ipv4` so the `tcp_reordering` upper bound follows that namespace's `tcp_max_reordering`. Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`. This keeps the send queue and window checks from being bypassed through signed integer overflow.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64423", "url": "https://ubuntu.com/security/CVE-2026-64423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: remove multicast group from hash table on device destruction When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through the multicast list and calls ip_ma_put() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mc_hash). Since the device remains published in dev->ip_ptr until after ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs. Fix this by unlinking the multicast group from mc_hash using ip_mc_hash_remove() before scheduling it for reclamation. BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276 Call Trace: dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 Allocated by task 2239: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40 __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300 Freed by task 0: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50 __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64425", "url": "https://ubuntu.com/security/CVE-2026-64425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 10dc95939817 (\"io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64429", "url": "https://ubuntu.com/security/CVE-2026-64429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: eic-sprd: use raw_spinlock_t in the irq startup path sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64430", "url": "https://ubuntu.com/security/CVE-2026-64430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid calling pci_irq_vector() from hardirq context ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive the vector number. pci_irq_vector() calls msi_get_virq() that takes a mutex and can therefore trigger \"scheduling while atomic\" splats: BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedule_preempt_disabled+0x28/0x50 __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf] __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64432", "url": "https://ubuntu.com/security/CVE-2026-64432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns In the analysis pass of $LogFile journal replay, log_replay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcns_follow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time: BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array: 1. dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow. 2. lrh->target_vcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge size_t. Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL. This mirrors the bounds-check pattern added in commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") and commit 0ca0485e4b2e (\"fs/ntfs3: validate rec->used in journal-replay file record check\").", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68090", "url": "https://ubuntu.com/security/CVE-2026-68090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) \treturn; obj = alloc(); \t\t\t\tif (!obj) { \t\t\t\t\t\t\t// Out of memory \tdebug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized \tif (!IS_ERR_OR_NULL(obj)) \treturn; if (!obj) { \tdebug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64435", "url": "https://ubuntu.com/security/CVE-2026-64435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: Fix data races of skb_queue_len() readers on audit_queue Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races. All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn() KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 value changed: 0x00000001 -> 0x00000000 ================================================================== Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side. [PM: line length tweak]", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64436", "url": "https://ubuntu.com/security/CVE-2026-64436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: initialize alg_key_len for IPComp states pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name: \tx->calg = kmalloc_obj(*x->calg); \tif (!x->calg) { \t\terr = -ENOMEM; \t\tgoto out; \t} \tstrcpy(x->calg->alg_name, a->name); \tx->props.calgo = sa->sadb_sa_encrypt; Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data. calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE: \txfrm_state_migrate() \t xfrm_state_clone_and_setup() \t x->calg = xfrm_algo_clone(orig->calg); \t kmemdup(orig, xfrm_alg_len(orig)); where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0): BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90 ___sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4) Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail. The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent. Initialize calg->alg_key_len to 0, matching the aalg/ealg branches.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64599", "url": "https://ubuntu.com/security/CVE-2026-64599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: amlogic - avoid double cleanup in meson_crypto_probe() When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker(). Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM. ================================================================== BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0 Read of size 8 at addr ff1100010c057a68 by task insmod/265 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? kthread_destroy_worker+0xb2/0xd0 ? kthread_destroy_worker+0xb2/0xd0 kasan_report+0xca/0x100 ? kthread_destroy_worker+0xb2/0xd0 kthread_destroy_worker+0xb2/0xd0 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto] platform_probe+0x99/0x140 really_probe+0x1c6/0x6a0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x248/0x310 ? acpi_driver_match_device+0xb0/0x100 driver_probe_device+0x48/0x210 ? __pfx___device_attach_driver+0x10/0x10 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x104/0x190 ? __pfx_bus_for_each_drv+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 __device_attach+0x19d/0x3b0 ? __pfx___device_attach+0x10/0x10 ? do_raw_spin_unlock+0x53/0x220 device_initial_probe+0x78/0xa0 bus_probe_device+0x5b/0x130 device_add+0xcfd/0x1430 ? __pfx_device_add+0x10/0x10 ? insert_resource+0x34/0x50 ? lock_release+0xc9/0x290 platform_device_add+0x24e/0x590 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro] meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro] do_one_initcall+0xc0/0x450 ? __pfx_do_one_initcall+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 ? __create_object+0x59/0x80 ? kasan_unpoison+0x27/0x60 do_init_module+0x27b/0x7d0 ? __pfx_do_init_module+0x10/0x10 ? kasan_quarantine_put+0x84/0x1d0 ? kfree+0x32c/0x510 ? load_module+0x561e/0x5ff0 load_module+0x54fe/0x5ff0 ? __pfx_load_module+0x10/0x10 ? security_file_permission+0x20/0x40 ? kernel_read_file+0x23d/0x6e0 ? mmap_region+0x235/0x4a0 ? __pfx_kernel_read_file+0x10/0x10 ? __file_has_perm+0x2c0/0x3e0 init_module_from_file+0x158/0x180 ? __pfx_init_module_from_file+0x10/0x10 ? __lock_acquire+0x45a/0x1ba0 ? idempotent_init_module+0x315/0x610 ? lock_release+0xc9/0x290 ? lock ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64440", "url": "https://ubuntu.com/security/CVE-2026-64440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB write in HT_caps_handler() HT_caps_handler() iterates pIE->length bytes and writes into HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct HT_caps_element). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlme_ext_info. Truncate the iteration count to the size of HT_caps.u.HT_cap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HT_caps_enable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64536", "url": "https://ubuntu.com/security/CVE-2026-64536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop The loop in is_ap_in_tkip() iterates over IEs without verifying that enough bytes remain before dereferencing the IE header or its payload: - pIE->element_id and pIE->length are read without checking that i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the buffer causes an OOB read. - For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12, which requires pIE->length >= 16. For WLAN_EID_RSN it compares pIE->data + 8, requiring pIE->length >= 12. Neither requirement is checked. Add the missing IE header and payload bounds checks and guard each data access with an explicit pIE->length minimum, matching the pattern established in update_beacon_info().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-64442", "url": "https://ubuntu.com/security/CVE-2026-64442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64443", "url": "https://ubuntu.com/security/CVE-2026-64443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the element_id byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64444", "url": "https://ubuntu.com/security/CVE-2026-64444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i < pkt_len. When a malicious AP sends an AssocResponse whose last IE has only one byte remaining in the frame (the element_id byte lands at pkt_len-1), the loop reads pIE->length from pframe[pkt_len], which is one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pkt_len, silently passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pkt_len.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64445", "url": "https://ubuntu.com/security/CVE-2026-64445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth() OnAuth() has two bugs in the shared-key authentication path. When the Privacy bit is set, rtw_wep_decrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtw_wep_decrypt(), length is computed as: length = len - WLAN_HDR_A3_LEN - iv_len and then passed as (length - 4) to crc32_le(). If len is less than WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative and, after the implicit cast to size_t, causes crc32_le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path. When processing a seq=3 response, rtw_get_ie() stores the Challenge Text IE length in ie_len, but the subsequent memcmp() always reads 128 bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64450", "url": "https://ubuntu.com/security/CVE-2026-64450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it (\"if (glen > dlen) break;\"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: \tthis_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), \t\t\t GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: \"if (glen > dlen) break;\" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means \"legacy peer without Selective ACK\", a distinct legitimate state.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64452", "url": "https://ubuntu.com/security/CVE-2026-64452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix NHC entry use-after-free on error path lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding lowpan_nhc_lock. If the descriptor has no uncompress callback, the error path drops the lock before printing nhc->name. lowpan_nhc_del() removes descriptors under the same lock and then relies on synchronize_net() before the owning module can be unloaded. That only waits for net RX RCU readers. lowpan_header_decompress() is also exported and can be reached from callers that are not necessarily covered by the net core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive path. This leaves a race where one task drops lowpan_nhc_lock in the error path, another task unregisters and frees the matching descriptor after synchronize_net() returns, and the first task then dereferences nhc->name for the warning. With the post-unlock window widened, KASAN reports: BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220 Read of size 8 lowpan_nhc_do_uncompression lowpan_header_decompress Fix this by printing the warning before dropping lowpan_nhc_lock, so the descriptor name is read while unregister is still excluded. The malformed packet is still rejected with -ENOTSUPP.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64454", "url": "https://ubuntu.com/security/CVE-2026-64454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: run gadget disconnect from sleepable suspend context dwc3_gadget_suspend() takes dwc->lock with IRQs disabled and then calls dwc3_disconnect_gadget(). For async callbacks that helper only uses plain spin_unlock()/spin_lock(), so the gadget ->disconnect() callback still runs with IRQs disabled and any sleepable callback trips Lockdep. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the dwc3_gadget_suspend() -> dwc3_disconnect_gadget() -> gadget_driver->disconnect() chain, and Lockdep reported: BUG: sleeping function called from invalid context gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] Keep the disconnect callback selection in one common helper, but add a sleepable suspend-side wrapper which snapshots the callback under dwc->lock and then runs it after spin_unlock_irqrestore(). The regular event path still uses the existing spin_unlock()/spin_lock() window.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64455", "url": "https://ubuntu.com/security/CVE-2026-64455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: chaoskey: Fix slab-use-after-free in chaoskey_release() The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: \tBUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) \tRead of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 \tHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 \tCall Trace: \t \t dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) \t print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) \t kasan_report (mm/kasan/report.c:595) \t dev_driver_string (drivers/base/core.c:2406) \t __dynamic_dev_dbg (lib/dynamic_debug.c:906) \t chaoskey_release (drivers/usb/misc/chaoskey.c:323) \t __fput (fs/file_table.c:510) \t fput_close_sync (fs/file_table.c:615) \t __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) \t do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) \t entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64456", "url": "https://ubuntu.com/security/CVE-2026-64456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: virtio: clamp device-reported used.len at copy_data() random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64189", "url": "https://ubuntu.com/security/CVE-2026-64189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64465", "url": "https://ubuntu.com/security/CVE-2026-64465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix sleep in atomic context in xhci_free_streams() When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64468", "url": "https://ubuntu.com/security/CVE-2026-64468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_free_transaction() In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64469", "url": "https://ubuntu.com/security/CVE-2026-64469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_thread_release() When a thread exits, binder_thread_release() walks its transaction stack to clear the t->from and t->to_proc that correspond with the exiting thread. However, a process dying in parallel might attempt to kfree some of these transactions. And if one of them has no associated t->to_proc, the t->to_proc->inner_lock will not be acquired. This means that transaction accesses in binder_thread_release() after t->to_proc has been cleared might race with binder_free_transaction() and cause a use-after-free error as reported by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798 Write of size 8 at addr ffff000016627500 by task X/715 CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...] Allocated by task 717 on cpu 18 at 67.267803s: __kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+0x554/0x8150 binder_thread_write+0xa30/0x4354 binder_ioctl+0x20f0/0x299c [...] Freed by task 202 on cpu 18 at 90.416221s: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_free_transaction+0x150/0x294 binder_send_failed_reply+0x398/0x6d8 binder_release_work+0x3e4/0x4ec binder_deferred_func+0xbd8/0x104c [...] ================================================================== In order to avoid this, make sure that binder_free_transaction() reads the t->to_proc under the transaction lock. This will serialize the transaction release with the accesses in binder_thread_release(). Plus, it matches the documented locking rules for @to_proc.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64470", "url": "https://ubuntu.com/security/CVE-2026-64470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on marvell probe failure Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64471", "url": "https://ubuntu.com/security/CVE-2026-64471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on registration failure Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64478", "url": "https://ubuntu.com/security/CVE-2026-64478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64483", "url": "https://ubuntu.com/security/CVE-2026-64483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. \tcount = be32_to_cpu(payload->sample_count); \tif (likely(count <= (length - 16) / 4)) \t\tisight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64484", "url": "https://ubuntu.com/security/CVE-2026-64484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es1938: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. snd_es1938_mixer() does not check the return value before dereferencing the pointer, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64487", "url": "https://ubuntu.com/security/CVE-2026-64487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every iteration it advances buf and subtracts the block size while looping on \"while (len)\". len is urb->actual_length. That value is supplied by the device and is not guaranteed to be a multiple of 16. When a final short block leaves len between 1 and 15, the loop runs once more, reads up to buf[15], and then does \"len -= TKS4_MSGBLOCK_SIZE\". As len is unsigned this underflows to a huge value. The loop then keeps iterating and walking buf far past the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus block id happens to be hit. Iterate only while a full message block is available. This stops the unsigned underflow and silently drops any trailing partial block, which carries no complete control value anyway. The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1 and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor urb->actual_length before dispatching.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64494", "url": "https://ubuntu.com/security/CVE-2026-64494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: fix runtime PM leak on read error gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the \"out\" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a \"goto out\" to ensure the reference is properly dropped on the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64495", "url": "https://ubuntu.com/security/CVE-2026-64495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: bmg160: bail out when bandwidth/filter is not in table bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: \tfor (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { \t\tif (bmg160_samp_freq_table[i].bw_bits == bw_bits) \t\t\tbreak; \t} \t*val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64496", "url": "https://ubuntu.com/security/CVE-2026-64496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64497", "url": "https://ubuntu.com/security/CVE-2026-64497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64602", "url": "https://ubuntu.com/security/CVE-2026-64602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: spear: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in spear_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, spear_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ spear_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64500", "url": "https://ubuntu.com/security/CVE-2026-64500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: lpc32xx: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64503", "url": "https://ubuntu.com/security/CVE-2026-64503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64504", "url": "https://ubuntu.com/security/CVE-2026-64504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer \tu16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: \tcount = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: \tif (samples && count > samples) \t\tcount = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: \tbmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64505", "url": "https://ubuntu.com/security/CVE-2026-64505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check for header Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68088", "url": "https://ubuntu.com/security/CVE-2026-68088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check to response query Add variable representations for BufLength and BufOffset in rndis_query_response(), and perform a length check on them. This is identical to how rndis_set_response() handles these parameters.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-53392", "url": "https://ubuntu.com/security/CVE-2026-53392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53402", "url": "https://ubuntu.com/security/CVE-2026-53402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font() When fbcon_do_set_font() fails (e.g., due to a memory allocation failure inside vc_resize() under heavy memory pressure), it jumps to the `err_out` label to roll back the console state. However, the current rollback logic forgets to restore the `hi_font` state, leading to a severe state machine corruption. Earlier in the function, `set_vc_hi_font()` might be called to change `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()` subsequently fails, the `err_out` path restores `vc_font.charcount` but entirely skips rolling back the `vc_hi_font_mask` and the screen buffer. This mismatch leaves the terminal in a desynchronized state. Because `vc_hi_font_mask` remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure. Fix this by adding the missing rollback logic for the `hi_font` mask and screen buffer in the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63810", "url": "https://ubuntu.com/security/CVE-2026-63810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Avoid mounting the bdev pseudo-filesystem in userspace The bdev pseudo-filesystem is an internal kernel filesystem with which userspace should not interfere. Unregister it so that userspace cannot even attempt to mount it. This fixes a bug [1] that occurs when attempting to access files, because the system call move_mount() uses pointers declared in the inode_operations structure, which for the bdev pseudo-filesystem are always equal to 0. `inode->i_op = &empty_iops;` [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:0x0 Call Trace: lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460 open_last_lookups fs/namei.c:3550 [inline] path_openat+0x953/0x2700 fs/namei.c:3780 do_filp_open+0x1c5/0x410 fs/namei.c:3810 do_sys_openat2+0x171/0x4d0 fs/open.c:1318 do_sys_open fs/open.c:1334 [inline] __do_sys_openat fs/open.c:1350 [inline] __se_sys_openat fs/open.c:1345 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68459", "url": "https://ubuntu.com/security/CVE-2026-68459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs() When we mount device w/ gc_merge mount option, we may suffer below potential deadlock: Kworker\t\t\t\t\tGC trehad\t\t\tTruncator - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback --- set writeback flag on folio - f2fs_outplace_write_data : cached folio in internal bio cache - f2fs_balance_fs - wake_up(gc_thread) : wake up gc thread to run foreground GC - finish_wait(fggc_wq) : wait on the waitqueue --- wait on GC thread to finish the work \t\t\t\t\t\t\t\t\t- truncate_inode_pages_range \t\t\t\t\t\t\t\t\t - __filemap_get_folio(, FGP_LOCK) --- lock folio \t\t\t\t\t\t\t\t\t - truncate_inode_partial_folio \t\t\t\t\t\t\t\t\t - folio_wait_writeback --- wait on writeback being cleared \t\t\t\t\t- do_garbage_collect \t\t\t\t\t - move_data_page \t\t\t\t\t - f2fs_get_lock_data_folio \t\t\t\t\t - lock on folio --- blocked on folio's lock In order to avoid such deadlock, let's call below functions to commit cached bios in GC_MERGE path of f2fs_balance_fs() as the same as we did in NOGC_MERGE path. - f2fs_submit_merged_write(sbi, DATA); - f2fs_submit_all_merged_ipu_writes(sbi);", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-68460", "url": "https://ubuntu.com/security/CVE-2026-68460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in f2fs_balance_fs() When the f2fs filesystem space is nearly exhausted, we encounter deadlock issues as below: INFO: task A:1890 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:A state:D stack:0 pid:1890 tgid:1626 ppid:1153 flags:0x00000204 Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 folio_wait_bit+0x20/0x38 folio_wait_writeback+0x54/0xc8 truncate_inode_partial_folio+0x70/0x1e0 truncate_inode_pages_range+0x1b0/0x450 truncate_pagecache+0x54/0x88 f2fs_file_write_iter+0x3e8/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task kworker/u8:11:2680853 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:11 state:D stack:0 pid:2680853 tgid:2680853 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 __filemap_get_folio+0x214/0x348 pagecache_get_page+0x20/0x70 f2fs_get_read_data_page+0x150/0x3e8 f2fs_get_lock_data_page+0x2c/0x160 move_data_page+0x50/0x478 do_garbage_collect+0xd38/0x1528 f2fs_gc+0x240/0x7e0 f2fs_balance_fs+0x1a0/0x208 f2fs_write_single_data_page+0x6e4/0x730 f2fs_write_cache_pages+0x378/0x9b0 f2fs_write_data_pages+0x2e4/0x388 do_writepages+0x8c/0x2c8 __writeback_single_inode+0x4c/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x200 INFO: task kworker/u8:8:2641297 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:8 state:D stack:0 pid:2641297 tgid:2641297 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_write_inode+0xf4/0x328 __writeback_single_inode+0x370/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x20 INFO: task B:1902 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:B state:D stack:0 pid:1902 tgid:1626 ppid:1153 flags:0x0000020c Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_map_blocks+0x94c/0x1110 f2fs_file_write_iter+0x228/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task sync:2769849 blocked for more than 120 seconds. Tainted: G ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63815", "url": "https://ubuntu.com/security/CVE-2026-63815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: bound i_inline_xattr_size for non-inline-xattr inodes When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: \tif (f2fs_sb_has_flexible_inline_xattr(sbi)) \t\tfi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: \tMAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) \tNR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) \taddrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: \twhile (bit_pos < d->max)\t\t/* fs/f2fs/dir.c */ \t\t... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ... Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files. Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63818", "url": "https://ubuntu.com/security/CVE-2026-63818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate orphan inode entry count f2fs_recover_orphan_inodes() trusts the orphan block entry_count when replaying orphan inodes from the checkpoint pack. A corrupted entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the ino[] array and interpret footer or following data as inode numbers. On a crafted image, mounting an unpatched kernel can drive orphan recovery into f2fs_bug_on() and panic the kernel. Validate entry_count before consuming entries so corrupted checkpoint data fails the mount with -EFSCORRUPTED and requests fsck instead. Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be recorded in the superblock s_errors[] field. This gives fsck a persistent hint even though mount-time orphan recovery failure may leave no chance to persist SBI_NEED_FSCK through a checkpoint.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68461", "url": "https://ubuntu.com/security/CVE-2026-68461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device property: initialize the remaining fields of fwnode_handle in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitialized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. While at it: initialize the remaining fields of struct fwnode_handle too just to be sure. [ Fix typo in commit message. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63829", "url": "https://ubuntu.com/security/CVE-2026-63829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper. Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs. Commit 8b484efd5cb4 (\"ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\") added the same check on the ioctl path. This adds it on RTM_NEWLINK.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2022-3114", "url": "https://ubuntu.com/security/CVE-2022-3114", "cve_description": "An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference.", "cve_priority": "negligible", "cve_public_date": "2022-12-14 21:15:00 UTC" }, { "cve": "CVE-2026-64514", "url": "https://ubuntu.com/security/CVE-2026-64514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is \"is this fault still WP-blocked?\". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says \"wait\", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns \"don't wait\" and lets the fault path retry.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53399", "url": "https://ubuntu.com/security/CVE-2026-53399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: release layout stid on setlease failure nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "high", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-31451", "url": "https://ubuntu.com/security/CVE-2026-31451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption. The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-43355", "url": "https://ubuntu.com/security/CVE-2026-43355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: bh1780: fix PM runtime leak on error path Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53139", "url": "https://ubuntu.com/security/CVE-2026-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23364", "url": "https://ubuntu.com/security/CVE-2026-23364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Compare MACs in constant time To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-46208", "url": "https://ubuntu.com/security/CVE-2026-46208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2023-54271", "url": "https://ubuntu.com/security/CVE-2023-54271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init blk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This happens because iocg->ioc is NULL. The field is initialized by ioc_pd_init() and never cleared. The NULL deref is caused by blkcg_activate_policy() installing blkg_policy_data before initializing it. blkcg_activate_policy() was doing the following: 1. Allocate pd's for all existing blkg's and install them in blkg->pd[]. 2. Initialize all pd's. 3. Online all pd's. blkcg_activate_policy() only grabs the queue_lock and may release and re-acquire the lock as allocation may need to sleep. ioc_weight_write() grabs blkcg->lock and iterates all its blkg's. The two can race and if ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a pd which is not initialized yet, leading to crash. The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c \"echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos\" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weight with the following patch applied: > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index fc49be622e05..38d671d5e10c 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol) > \t\tpd->online = false; > \t} > > + if (system_state == SYSTEM_RUNNING) { > + spin_unlock_irq(&q->queue_lock); > + ssleep(1); > + spin_lock_irq(&q->queue_lock); > + } > + > \t/* all allocated, init in the same order */ > \tif (pol->pd_init_fn) > \t\tlist_for_each_entry_reverse(blkg, &q->blkg_list, q_node) I don't see a reason why all pd's should be allocated, initialized and onlined together. The only ordering requirement is that parent blkgs to be initialized and onlined before children, which is guaranteed from the walking order. Let's fix the bug by allocating, initializing and onlining pd for each blkg and holding blkcg->lock over initialization and onlining. This ensures that an installed blkg is always fully initialized and onlined removing the the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53189", "url": "https://ubuntu.com/security/CVE-2026-53189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-52918", "url": "https://ubuntu.com/security/CVE-2026-52918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46160", "url": "https://ubuntu.com/security/CVE-2026-46160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix missing last_unlink_trans update when removing a directory When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path \"/mnt/dir1\" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] \t\tinode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] \t\trdev 0 sequence 2 flags 0x0 [445771.638102] \t\tatime 1775744884.0 [445771.660056] \t\tctime 1775744885.645502983 [445771.660058] \t\tmtime 1775744885.645502983 [445771.660060] \t\totime 1775744884.0 [445771.660062] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] \t\tindex 0 name_len 2 [445771.660066] \titem 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] \t\tlocation key (259 1 0) type 2 [445771.660070] \t\ttransid 9 data_len 0 name_len 4 [445771.660075] \titem 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] \t\tlocation key (257 1 0) type 2 [445771.660077] \t\ttransid 9 data_len 0 name_len 4 [445771.660078] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] \t\tlocation key (257 1 0) type 2 [445771.660080] \t\ttransid 9 data_len 0 name_len 4 [445771.660081] \titem 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] \t\tlocation key (259 1 0) type 2 [445771.660083] \t\ttransid 9 data_len 0 name_len 4 [445771.660084] \titem 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] \t\tinode generation 9 transid 9 size 8 nbytes 0 [445771.660087] \t\tblock group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] \t\trdev 0 sequence 2 flags 0x0 [445771.660089] \t\tatime 1775744885.641174097 [445771.660090] \t\tctime 1775744885.645502983 [445771.660091] \t\tmtime 1775744885.645502983 [445771.660105] \t\totime 1775744885.641174097 [445771.660106] \titem 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] \t\tindex 2 name_len 4 [445771.660108] \titem 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] \t\tlocation key (2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46292", "url": "https://ubuntu.com/security/CVE-2026-46292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46159", "url": "https://ubuntu.com/security/CVE-2026-46159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46191", "url": "https://ubuntu.com/security/CVE-2026-46191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46116", "url": "https://ubuntu.com/security/CVE-2026-46116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: \tif (x->km.seq) \t\thlist_del_rcu(&x->byseq); \tif (x->id.spi) \t\thlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46193", "url": "https://ubuntu.com/security/CVE-2026-46193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46180", "url": "https://ubuntu.com/security/CVE-2026-46180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31709", "url": "https://ubuntu.com/security/CVE-2026-31709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-46196", "url": "https://ubuntu.com/security/CVE-2026-46196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46291", "url": "https://ubuntu.com/security/CVE-2026-46291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46090", "url": "https://ubuntu.com/security/CVE-2026-46090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 (\"ALSA: aloop: Fix racy access at PCM trigger\") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46052", "url": "https://ubuntu.com/security/CVE-2026-46052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are unhashed Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume \"negative\" also means \"unhashed\": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45999", "url": "https://ubuntu.com/security/CVE-2026-45999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: \"outpages - inpages\" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46103", "url": "https://ubuntu.com/security/CVE-2026-46103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46056", "url": "https://ubuntu.com/security/CVE-2026-46056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46299", "url": "https://ubuntu.com/security/CVE-2026-46299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: \t========================= \tWARNING: held lock freed! \t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted \t------------------------- \tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! \tffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \t2 locks held by mount/174: \t#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 \t#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \tstack backtrace: \tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tCall Trace: \t \tdump_stack_lvl+0x82/0xd0 \tdebug_check_no_locks_freed+0x13a/0x180 \tkfree+0x16b/0x510 \t? hfsplus_fill_super+0xcb4/0x18a0 \thfsplus_fill_super+0xcb4/0x18a0 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x65f/0xc30 \t? srso_return_thunk+0x5/0x5f \t? pointer+0x4ce/0xbf0 \t? trace_contention_end+0x11c/0x150 \t? __pfx_pointer+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x79b/0xc30 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? vsnprintf+0x6da/0x1270 \t? srso_return_thunk+0x5/0x5f \t? __mutex_unlock_slowpath+0x157/0x740 \t? __pfx_vsnprintf+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? mark_held_locks+0x49/0x80 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? irqentry_exit+0x17b/0x5e0 \t? trace_irq_disable.constprop.0+0x116/0x150 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? __pfx_hfsplus_fill_super+0x10/0x10 \tget_tree_bdev_flags+0x302/0x580 \t? __pfx_get_tree_bdev_flags+0x10/0x10 \t? vfs_parse_fs_qstr+0x129/0x1a0 \t? __pfx_vfs_parse_fs_qstr+0x3/0x10 \tvfs_get_tree+0x89/0x320 \tfc_mount+0x10/0x1d0 \tpath_mount+0x5c5/0x21c0 \t? __pfx_path_mount+0x10/0x10 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? kmem_cache_free+0x307/0x540 \t? user_path_at+0x51/0x60 \t? __x64_sys_mount+0x212/0x280 \t? srso_return_thunk+0x5/0x5f \t__x64_sys_mount+0x212/0x280 \t? __pfx___x64_sys_mount+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \tdo_syscall_64+0x111/0x680 \tentry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7ffacad55eae \tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 \tRSP: 002b ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46169", "url": "https://ubuntu.com/security/CVE-2026-46169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45991", "url": "https://ubuntu.com/security/CVE-2026-45991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46065", "url": "https://ubuntu.com/security/CVE-2026-46065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46086", "url": "https://ubuntu.com/security/CVE-2026-46086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46003", "url": "https://ubuntu.com/security/CVE-2026-46003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46038", "url": "https://ubuntu.com/security/CVE-2026-46038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46026", "url": "https://ubuntu.com/security/CVE-2026-46026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46091", "url": "https://ubuntu.com/security/CVE-2026-46091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46078", "url": "https://ubuntu.com/security/CVE-2026-46078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46069", "url": "https://ubuntu.com/security/CVE-2026-46069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46021", "url": "https://ubuntu.com/security/CVE-2026-46021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46092", "url": "https://ubuntu.com/security/CVE-2026-46092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: check for PCI upstream bridge existence pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31700", "url": "https://ubuntu.com/security/CVE-2026-31700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31712", "url": "https://ubuntu.com/security/CVE-2026-31712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require minimum ACE size in smb_check_perm_dacl() Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31708", "url": "https://ubuntu.com/security/CVE-2026-31708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43350", "url": "https://ubuntu.com/security/CVE-2026-43350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: require a full NFS mode SID before reading mode bits parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31711", "url": "https://ubuntu.com/security/CVE-2026-31711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix active_num_conn leak on transport allocation failure Commit 77ffbcac4e56 (\"smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with \"Limit the maximum number of connections\". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31715", "url": "https://ubuntu.com/security/CVE-2026-31715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() The xfstests case \"generic/107\" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43492", "url": "https://ubuntu.com/security/CVE-2026-43492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting \"lzeros\" from the unsigned \"nbytes\". For this to happen, the scatterlist \"sgl\" needs to occupy more bytes than the \"nbytes\" parameter and the first \"nbytes + 1\" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than \"nbytes\", subtract the number of zeroes from \"nbytes\" and cause the underflow. When commit 2d4d1eea540b (\"lib/mpi: Add mpi sgl helpers\") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to \"nbytes\". However since commit 63ba4d67594a (\"KEYS: asymmetric: Use new crypto interface without scatterlists\"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger \"out_len\" than \"in_len\" and filling the \"in\" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the \"src\" and \"dst\" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "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.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-52933", "url": "https://ubuntu.com/security/CVE-2026-52933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix signed comparison in io_poll_get_ownership() io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2025-22026", "url": "https://ubuntu.com/security/CVE-2025-22026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2023-54125", "url": "https://ubuntu.com/security/CVE-2023-54125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Return error for inconsistent extended attributes ntfs_read_ea is called when we want to read extended attributes. There are some sanity checks for the validity of the EAs. However, it fails to return a proper error code for the inconsistent attributes, which might lead to unpredicted memory accesses after return. [ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0 [ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199 [ 138.931132] [ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4 [ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 138.947327] Call Trace: [ 138.949557] [ 138.951539] dump_stack_lvl+0x4d/0x67 [ 138.956834] print_report+0x16f/0x4a6 [ 138.960798] ? ntfs_set_ea+0x453/0xbf0 [ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200 [ 138.969793] ? ntfs_set_ea+0x453/0xbf0 [ 138.973523] kasan_report+0xb8/0x140 [ 138.976740] ? ntfs_set_ea+0x453/0xbf0 [ 138.980578] __asan_store4+0x76/0xa0 [ 138.984669] ntfs_set_ea+0x453/0xbf0 [ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10 [ 138.993390] ? kernel_text_address+0xd3/0xe0 [ 138.998270] ? __kernel_text_address+0x16/0x50 [ 139.002121] ? unwind_get_return_address+0x3e/0x60 [ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 139.010177] ? arch_stack_walk+0xa2/0x100 [ 139.013657] ? filter_irq_stacks+0x27/0x80 [ 139.017018] ntfs_setxattr+0x405/0x440 [ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10 [ 139.026569] ? kvmalloc_node+0x2d/0x120 [ 139.030329] ? kasan_save_stack+0x41/0x60 [ 139.033883] ? kasan_save_stack+0x2a/0x60 [ 139.037338] ? kasan_set_track+0x29/0x40 [ 139.040163] ? kasan_save_alloc_info+0x1f/0x30 [ 139.043588] ? __kasan_kmalloc+0x8b/0xa0 [ 139.047255] ? __kmalloc_node+0x68/0x150 [ 139.051264] ? kvmalloc_node+0x2d/0x120 [ 139.055301] ? vmemdup_user+0x2b/0xa0 [ 139.058584] __vfs_setxattr+0x121/0x170 [ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10 [ 139.066282] __vfs_setxattr_noperm+0x97/0x300 [ 139.070061] __vfs_setxattr_locked+0x145/0x170 [ 139.073580] vfs_setxattr+0x137/0x2a0 [ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10 [ 139.080223] ? __kasan_check_write+0x18/0x20 [ 139.084234] do_setxattr+0xce/0x150 [ 139.087768] setxattr+0x126/0x140 [ 139.091250] ? __pfx_setxattr+0x10/0x10 [ 139.094948] ? __virt_addr_valid+0xcb/0x140 [ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330 [ 139.102688] ? debug_smp_processor_id+0x1b/0x30 [ 139.105985] ? kasan_quarantine_put+0x5b/0x190 [ 139.109980] ? putname+0x84/0xa0 [ 139.113886] ? __kasan_slab_free+0x11e/0x1b0 [ 139.117961] ? putname+0x84/0xa0 [ 139.121316] ? preempt_count_sub+0x1c/0xd0 [ 139.124427] ? __mnt_want_write+0xae/0x100 [ 139.127836] ? mnt_want_write+0x8f/0x150 [ 139.130954] path_setxattr+0x164/0x180 [ 139.133998] ? __pfx_path_setxattr+0x10/0x10 [ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10 [ 139.141299] ? debug_smp_processor_id+0x1b/0x30 [ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80 [ 139.150796] __x64_sys_setxattr+0x71/0x90 [ 139.155407] do_syscall_64+0x3f/0x90 [ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 139.163843] RIP: 0033:0x7f108cae4469 [ 139.166481] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc [ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469 [ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6 [ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618 [ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0 [ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15 ---truncated---", "cve_priority": "high", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2026-31449", "url": "https://ubuntu.com/security/CVE-2026-31449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: validate p_idx bounds in ext4_ext_correct_indexes ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level. If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read. Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "high", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43064", "url": "https://ubuntu.com/security/CVE-2026-43064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix not releasing workqueue on .release() The workqueue associated with an DSA/IAA device is not released when the object is freed.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1109.114 -proposed tracker (LP: #2165588)", "", " [ Ubuntu: 5.15.0-198.208 ]", "", " * jammy/linux: 5.15.0-198.208 -proposed tracker (LP: #2166457)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192)", " - Input: ims-pcu - fix logic error in packet reset", " - KVM: VMX: Make vmread_error_trampoline() uncallable from C code", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - RDMA/siw: Only check attrs->cap.max_send_wr in siw_create_qp", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ata: sata_dwc_460ex: remove variable num_processed", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/time: Fix sparse warnings", " - powerpc: remove the last remnants of cputime_t", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - ASoC: bt-sco: fix bt-sco-pcm-wb dai widget don't connect to the endpoint", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - hwmon: (occ) Add sysfs entry for IPS (Idle Power Saver) status", " - hwmon: (occ) Add sysfs entry for OCC mode", " - hwmon: (occ) Add sysfs entries for additional extended status bits", " - hwmon: (occ) Delay hwmon registration until user request", " - net: dpaa2-eth: assign priv->mac after dpaa2_mac_connect() call", " - wifi: mac80211: recalculate TIM when a station enters power save", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: stmmac: add tc flower filter for EtherType matching", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - raw: use more conventional iterators", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - x86/boot/compressed: Disable jump tables", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - proc: Fix broken error paths for namespace links", " - ice: use READ_ONCE() to access cached PHC time", " - raw: remove unused variables from raw6_icmp_error()", " - raw: fix a typo in raw_icmp_error()", " - media: uvcvideo: Implement dual stream quirk to fix loss of usb packets", " - media: uvcvideo: Fix sequence number when no EOF", " - HID: logitech-dj: Standardise hid_report_enum variable nomenclature", " - HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB", " write", " - HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report", " - net: qrtr: ns: Raise node count limit to 512", " - dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA", " - ASoC: max98095: fix missing IS_ERR() before PTR_ERR() on mclk lookup", " - ASoC: max98090: fix missing IS_ERR() before PTR_ERR() on mclk lookup", " - phy: zynqmp: Allow variation in refclk rate", " - phy-zynqmp: Postpone getting clock rate until actually needed", " - phy: zynqmp: fix clock error handling in xpsgtr_phy_init()", " - phy: zynqmp: fix runtime PM leak on probe allocation failure", " - drm/mediatek: Check CRTC state before freeing", " - assoc_array: trim the final shortcut word using the current chunk end", " - smb: client: fix buffer leaks in SMB1 read and write", " - net: bridge: mrp: fix Option TLV length in MRP_Test frames", " - hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors", " - hwmon: (adt7470) Fix cache updated before hardware write on I2C error", " - hwmon: (adt7470) Fix temperature alarm logic in hwmon_temp_read()", " - hwmon: (adt7470) Fix swapped PWM3 and PWM4 auto mode masks", " - hwmon: (adt7470) Use cached PWM frequency value", " - hwmon: (adt7470) Fix PWM auto temp state array and bounds check", " - powerpc/boot: Fix simpleboot CPU node lookup check", " - powerpc/boot: Fix treeboot-currituck CPU node lookup check", " - powerpc/boot: Fix treeboot-akebono CPU node lookup check", " - wifi: mac80211: validate individual TWT params before driver setup", " - hwmon: (pmbus) Fix return value from pmbus_update_byte_data()", " - net: phylink: put link_gpio if phylink_create fails", " - scsi: zfcp: Fix memory leak during adapter release by destroying", " gid_pn_req", " - net: sxgbe: check descriptor ring allocation failures", " - can: isotp: check register_netdevice_notifier() error in module init", " - tracing/mmiotrace: Reset dropped_count in mmio_reset_data()", " - octeontx2-pf: Set correct sequence for carrier off and tx queue stop", " - pinctrl: bm1880: add missing select GENERIC_PINCONF", " - mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk()", " - sctp: validate Adaptation Indication parameter length", " - audit: fix potential integer overflow in audit_log_n_string()", " - bpf: lwt: Fix dst reference leak on reroute failure", " - ALSA: lx6464es: fix period byte count for 16-bit streams", " - ALSA: pcm: wake linked drain waiters on unlink", " - ASoC: tas2562: fix DVC coefficient write order", " - ASoC: tas2562: fix broken entries in the volume lookup table", " - dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+", " - e1000: fix memory leak in e1000_probe()", " - ipvs: do not propagate one-packet flag to synced conns", " - net: ipv6: clear suppressed fib6 rule result", " - powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()", " - vxlan: re-fetch eth header after route_shortcircuit()", " - vxlan: unclone skb head before modifying eth header in", " route_shortcircuit()", " - tracing/filters: Fix false positive match in regex_match_full()", " - selftests/clone3: fix wild pointer access of getline due to missing init", " - sctp: reject stale cookies with mismatched verification tags", " - hwmon: (npcm750-pwm-fan): stop fan timer on device detach", " - i2c: amd-mp2: Unregister callback on adapter add failure", " - cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init()", " - s390/dasd: Fix potential NULL pointer dereference", " - phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask", " - phy: zynqmp: use read-modify-write for SERDES scrambler bypass", " - phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB", " - can: c_can: c_can_chip_config(): keep controller in init mode until", " bittiming is configured", " - can: j1939: transport: j1939_session_fresh_new(): initialize receive", " buffer", " - can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in", " kvaser_usb_hydra_get_busparams()", " - can: softing: fw_parse(): validate firmware record spans", " - drm/amdgpu: restore UMD profile pstate after runtime resume", " - drm/amdgpu: cap GTT size to physical RAM on APUs", " - HID: logitech-dj: Fix maxfield check in DJ short report validation", " - net: openvswitch: fix skb leak on flow key update failure during", " recirculation", " - mount: honour SB_NOUSER in the new mount API", " - s390/zcrypt: Fix missing mem scrub at clear key import in", " cca_clr2cipherkey()", " - nfs4: take a reference on the nfs_client when running FREE_STATEID", " - NFS: Pin the 'struct nfs_server' during a FREE_STATEID call", " - ARM: npcm: Fix OF node refcount leaks in SMP setup", " - bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor", " - bpf: Preserve pointer state for commuted arithmetic", " - net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in", " smc_llc_event_handler()", " - net/sched: cls_route: fix fastmap use-after-free on filter", " - net: hisilicon: hix5hd2_gmac: remove redundant NAPI delete", " - net/mlx5: fw_tracer, return NULL on create error", " - counter: microchip-tcb-capture: Fix DT channel validation", " - vhost/vdpa: reject overflowing PA map page counts on 32-bit", " - udp: fix potential use-after-free in tunnel segmentation", " - net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter", " - net/openvswitch: check Ethernet header length in key_extract()", " - selftests/ftrace: Add test case for GRP/ only input", " - selftests/ftrace: refactor eprobes test to fix argument checks", " - bnxt_en: Do not set EOP on RX AGG BDs on 5760X chips", " - bnxt_en: Disable EOP for TPA on all chips to prevent data corruption", " - bnxt_en: Fix PTP PPS setting bug", " - sctp: fix addip_serial increment on ASCONF_ACK allocation failure", " - tcp: fix TFO max_qlen accounting across reuseport migration", " - net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length", " - net: prestera: validate firmware header length", " - net: remove WARN_ON_ONCE() from sk_mc_loop()", " - net/smc: fix TOCTOU race between smc_listen_out() and listener close", " - net: qrtr: ns: Raise lookup limit to 128", " - net: thunderbolt: Tear down DMA paths before stopping the rings", " - ata: pata_sl82c105: fix bridge revision use-after-free", " - sctp: clear control chunk transport if it is being removed", " - tls: don't abort the connection on signal-interrupted sends", " - hwmon: (corsair-psu) fix possible out-of-bounds access on missing string", " termination", " - spi: spi-fsl-dspi: Avoid setup_accel logic for DMA transfers", " - Input: evdev - sanitize event type index when fetching event masks", " - ALSA: usb-audio: fix OOB write on Type II inbound URBs", " - usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()", " - thunderbolt: icm: Preserve USB4 proxy data-valid bit", " - usb: cdnsp: fix incorrect endian conversions for APB timeout register", " - usb: gadget: f_ncm: Use unsigned int for ndp_index", " - ima: fix out-of-bounds read in xattr_verify()", " - ipvs: add totalconns for dest", " - ipvs: properly update the overload flag on dest edit", " - ipvs: clear IPv4 options after rebasing tunnel ICMP errors", " - net/packet: reset the MAC header on the packet-socket transmit path", " - net: openvswitch: reallocate update replies for mismatched IDs", " - net: octeontx2-pf: Fix UB in shift operation", " - net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header", " - netfilter: ebt_nflog: pin the NFLOG backend", " - net: bridge: mrp: fix uninitialised bytes on the wire", " - vt: add permission check for KDSKBMETA ioctl", " - vt: stabilize tty reference in kbd_keycode with tty_port_tty_get", " - Input: evdev - fix information leak in evdev_pass_values()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - futex: Prevent robust futex exit race some more", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - fscrypt: Replace mk_users keyring with simple list", " - ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops", " - ipv4: fix use-after-free in fib_nhc_update_mtu()", " - serial: 8250_dma: Clear stale RX state on shutdown", " - staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie()", " - staging: rtl8723bs: fix OOB read in WMM_param_handler()", " - staging: rtl8723bs: fix missing shared-key auth challenge length check", " - staging: rtl8723bs: validate monitor transmit frame lengths", " - misc: fastrpc: fix channel ctx ref leak when session alloc fails", " - misc: fastrpc: fix memory leak in fastrpc_channel_ctx_free", " - ALSA: usx2y: bound the hwdep mmap fault offset", " - tracing: Fix race between update_event_fields and, event_define_fields", " - fbdev: bitblit: bound-check glyph index in bit_cursor()", " - ipv6: prevent in6_dev_get() from resurrecting inet6_dev", " - netfilter: bridge: release template ct on non-IP path", " - net: atlantic: free RX pages of consumed but not refilled buffers", " - net/sched: act_gact, act_police: range check the fallback control action", " - xdp: reject clones that overrun skb_shared_info tailroom", " - vxlan: do not arm the ageing timer on a device that is down", " - vsock/virtio: read virtqueues under worker locks", " - vsock/virtio: avoid refilling the RX queue after teardown", " - vhost: reset the vring metadata cache on vring reconfiguration", " - tipc: read le->link under the node lock in tipc_node_link_down()", " - Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\"", " - ipv6: fix Route Information option length validation", " - ip6_tunnel: clear skb2->cb[] in ip6ip6_err()", " - bpf, sockmap: Fix sk_redir use-after-free in send verdict", " - scsi: scsi_debug: Negate wrapped memcmp() result", " - sctp: keep chunk->transport in step with the list it is queued on", " - sctp: fix use-after-free of cached ASCONF chunk", " - sctp: clear new_transport when removing a peer", " - thunderbolt: Bound the DROM dual link port number before indexing", " sw->ports", " - Linux 5.15.216", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64582", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74468", " - gpio: pch: use raw_spinlock_t for the register lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74482", " - mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74443", " - drm/vmwgfx: bound DMA command body size against suffix pointer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74444", " - drm/vmwgfx: validate DRAW_PRIMITIVES header size before division", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74453", " - drm/vc4: Zero the tile state data array before each BIN job", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74455", " - can: peak_usb: validate uCAN receive record lengths", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74456", " - can: peak_usb: peak_usb_start(): fix double free of transfer buffer on", " URB submit error", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74457", " - can: peak_usb: add bounds check for USB channel index", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74458", " - can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received", " command extents", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74459", " - can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB", " resubmit failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74460", " - can: ems_usb: validate CPC message lengths", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74461", " - i2c: imx: Cancel hrtimer before clearing slave pointer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74463", " - i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock", " deadlock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74464", " - net: openvswitch: fix skb leak on flow key update failure during ct", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74465", " - net: openvswitch: fix potential UAF on meter attach failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68451", " - s390/zcrypt: Validate length for CCA ECC private key requests", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68452", " - s390/zcrypt: Validate length for CCA AES cipher key requests", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74467", " - s390/qeth: Check CAP_NET_ADMIN for private ioctls", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74469", " - sctp: prevent peer transport count overflow", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74471", " - tracing: Check return value of __register_event() in", " trace_module_add_events()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74473", " - vxlan: use pskb_network_may_pull() in route_shortcircuit()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74475", " - vxlan: use neigh_ha_snapshot() in route_shortcircuit()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74478", " - um: vector: fix use-after-free in vector_mmsg_rx()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74480", " - net: bridge: stop fast-leave after deleting a port group", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74481", " - mm/page_reporting: use system_freezable_wq to fix UAF during suspend", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74485", " - binfmt_misc: reject a flag character as the field delimiter", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74488", " - wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74490", " - tipc: avoid use-after-free in poll trace queue dumps", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74492", " - netfilter: ipset: do not update comments from kernel-side hash adds", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74493", " - net/smc: fix socket use-after-free during link group termination", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74495", " - igbvf: Fix leak in TX DMA error cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74497", " - ALSA: usb-audio: Clamp frame size in implicit-feedback mode", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74498", " - ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74499", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74505", " - ALSA: 6fire: Fix UAF at error handling during probe", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74507", " - Bluetooth: HIDP: validate numbered report payloads", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74508", " - Bluetooth: HIDP: reject frames without a transaction header", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74512", " - audit: fix potential use-after-free in audit_del_rule()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74518", " - mm/hugetlb: fix list corruption in allocate_file_region_entries()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74519", " - pinctrl: devicetree: don't free uninitialized dev_name on error path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74523", " - qede: sync udp_tunnel ports outside qede_lock in the recovery path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74525", " - net: sxgbe: free TX rings on RX allocation failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74540", " - Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74546", " - hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74547", " - hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74548", " - forcedeth: fix UAF of txrx_stats in nv_remove", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74549", " - hwmon: (nct6775-core) Prevent access to unsupported weight registers", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74556", " - scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection", " buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74557", " - scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74563", " - rds: tcp: hold the RCU lock across ipv6_chk_addr() in", " rds_tcp_laddr_check()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74579", " - netfilter: nft_payload: fix mask build for partial field offload", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74564", " - netfilter: xt_hashlimit: validate hashtable supports", " XT_HASHLIMIT_RATE_MATCH", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74566", " - keys: make keyring key-chunk byte order agree with", " keyring_diff_objects()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74567", " - keys: fix out-of-bounds read in keyring_get_key_chunk()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74569", " - netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in", " sip_help_tcp()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-43491", " - net: qrtr: ns: Limit the maximum server registration per node", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74577", " - net: mpls: initialize rtm_tos in mpls_getroute()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64543", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72123", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72019", " - macsec: don't read an unset MAC header in macsec_encrypt()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-52977", " - futex: Prevent lockup in requeue-PI during signal/ timeout wakeup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * seccomp filter leak in bpf_jit due to unreaped zombie process", " (LP: #2164699)", " - seccomp: release task filters when the task exits", " * 5.15 kernel selftest srv6_end_dt6_l3vpn_test.sh failure (LP: #1961566)", " - SAUCE: selftest/net: skip srv6_end_dt6_l3vpn_test.sh if iproute2 too old", " * 5.15 kernel selftest srv6_end_dt4_l3vpn_test.sh failure (LP: #1956562)", " - SAUCE: selftest/net: skip srv6_end_dt4_l3vpn_test.sh if iproute2 too old", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", " * mount08 from ubuntu_ltp_syscalls failed - TFAIL: mount(/proc/139835/fd/4)", " succeeded (LP: #2137199)", " - proc: proc_readfd() -> proc_fd_iterate()", " - proc: proc_readfdinfo() -> proc_fdinfo_iterate()", " - proc: add proc_splice_unmountable()", " - proc: block mounting on top of /proc//map_files/*", " - proc: block mounting on top of /proc//fd/*", " - proc: block mounting on top of /proc//fdinfo/*", " * Jammy update: v5.15.215 upstream stable release (LP: #2165170)", " - Linux 5.15.215", " * Jammy update: v5.15.215 upstream stable release (LP: #2165170) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Jammy update: v5.15.214 upstream stable release (LP: #2165166)", " - Linux 5.15.214", " * Jammy update: v5.15.213 upstream stable release (LP: #2165125)", " - Linux 5.15.213", " * Jammy update: v5.15.213 upstream stable release (LP: #2165125) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124)", " - nfc: llcp: protect nfc_llcp_sock_unlink() calls", " - net/sched: act_pedit: use NLA_POLICY for parsing 'ex' keys", " - dma-buf: remove unused dma-fence-unwrap.c (stable/linux-5.15.y only)", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: Convert to platform remove callback returning void", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - skmsg: convert struct sk_msg_sg::copy to a bitmap", " - f2fs: fix to detect corrupted meta ino", " - f2fs: adjust zone capacity when considering valid block count", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: fix listxattr handling of corrupted xattr entries", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - PCI: altera: Do not dispose parent IRQ mapping", " - PCI: host-common: Request bus reassignment when not probe-only", " - virtio-mmio: fix device release warning on module unload", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - fuse: fix device node leak in cuse_process_init_reply()", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - tools/mm/slabinfo: fix total_objects attribute name", " - net: dsa: tag_ksz: do not rely on skb_mac_header() in TX paths", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - [Config] Remove CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - afs: Fix further netns teardown to cancel the preallocation charger", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - thermal: hwmon: Fix critical temperature attribute removal", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Fix UAF in strset__add_str()", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ARM: imx3: Fix CCM node reference leak", " - ARM: imx31: Fix IIM mapping leak in revision check", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - mm/fake-numa: fix under-allocation detection in uniform split", " - lib/test_meminit: use && for bools", " - bpftool: Use libbpf error code for flow dissector query", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Introduce SNDRV_SEQ_IOCTL_USER_PVERSION ioctl", " - ALSA: seq: Add UMP support", " - [Config] Disable CONFIG_SND_SEQ_UMP=n", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - hwspinlock: qcom: avoid uninitialized struct members", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - bonding: 3ad: fix mux port state on oper down", " - selftests/bpf: Fix bpf_iter/task_vma test", " - s390/process: Fix kernel thread function pointer type", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - crypto: rng - Free default RNG on module exit", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - netfilter: nf_conncount: callers must hold rcu read lock", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: zero-initialize the fib lookup flow struct", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - veth: fix NAPI leak in XDP enable error path", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - qede: fix out-of-bounds check for cqe->len_list[]", " - rtnetlink: change nlk->cb_mutex role", " - rtnetlink: add RTNL_FLAG_DUMP_UNLOCKED flag", " - inet: allow ip_valid_fib_dump_req() to be called with RTNL or RCU", " - ipv6: remove RTNL protection from inet6_dump_fib()", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - net/sched: hhf: clear heavy-hitter state on reset", " - afs: Fix vllist leak", " - afs: Fix unchecked-length string display in debug statement", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - net: qualcomm: rmnet: add tx packets aggregation", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - octeontx2-af: debugfs: Add channel and channel mask.", " - octeontx2-af: Use hashed field in MCAM key", " - octeontx2-af: Exact match support", " - octeontx2-af: Exact match scan from kex profile", " - octeontx2-af: devlink configuration support", " - octeontx2-af: FLR handler for exact match table.", " - octeontx2-af: Drop rules for NPC MCAM", " - octeontx2-af: Allow mkex profile without DMAC and add L2M/L2B header", " extraction support", " - octeontx2-pf: Add additional checks while configuring ucast/bcast/mcast", " rules", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - regulator: core: Make regulator_lock_two() logic easier to follow", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_nat: reject unsupported target families", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - x86/boot: Reject too long acpi_rsdp= values", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: fix VLAN priority offset", " - mfd: tps6586x: Fix OF node refcount", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - proc: only bump parent nlink when registering directories", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - xfrm: use compat translator only for u64 alignment mismatch", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - time: Fix off-by-one in compat settimeofday() usec validation", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm-verity: increase sprintf buffer size", " - scsi: sg: Report request-table problems when any status is set", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - gpios: palmas: add .get_direction() op", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - hwmon: (asus_atk0110) Check package count before accessing element", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - wifi: mac80211: free ack status frame on TX header build failure", " - mtd: onenand: samsung: report DMA completion timeouts", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: imu: inv_icm42600: make timestamp module chip independent", " - iio: move inv_icm42600 timestamp module in common", " - iio: make invensense timestamp module generic", " - iio: imu: inv_mpu6050: use the common inv_sensors timestamp module", " - [Config] Enable CONFIG_IIO_INV_SENSORS_TIMESTAMP=m", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - cifs: Create a new shared file holding smb2 pdu definitions", " - cifs: remove check of list iterator against head past the loop body", " - smb2: small refactor in smb2_check_message()", " - cifs: remove unused server parameter from calc_smb_size()", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - staging: rtl8723bs: Fix indentation issues", " - staging: rtl8723bs: Fix space issues", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - staging: rtl8723bs: Remove redundant else branches.", " - staging: rtl8723bs: remove redundant braces in if statements", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use new GPIO line value setter callbacks", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()", " - cifs: Add tracing for the cifs_tcon struct refcounting", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger", " - ksmbd: destroy async_ida in ksmbd_conn_free()", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - X.509: Fix validation of ASN.1 certificate header", " - proc: use generic setattr() for /proc/$PID/net", " - proc: Move fdinfo PTRACE_MODE_READ check into the inode .permission", " operation", " - proc: rename proc_setattr to proc_nochmod_setattr", " - HID: add haptics page defines", " - treewide: Switch/rename to timer_delete[_sync]()", " - serial: 8250_mid: Remove 8250_pci usage", " - serial: 8250_mid: Disable DMA for selected platforms", " - xfs: Remove redundant assignment of mp", " - xfs: Remove dead code", " - xfs: use null daddr for unset first bad log block", " - hfs/hfsplus: prevent getting negative values of offset/length", " - xdp: introduce flags field in xdp_buff/xdp_frame", " - bpf: Convert lpm_trie.c to rqspinlock", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - usb: iowarrior: remove inherent race with minor number", " - drm/i2c/sil164: Drop no-op remove function", " - leds: lm3697: Remove duplicated error reporting in .remove()", " - leds: lm3601x: Improve error reporting for problems during .remove()", " - gpio: pca953x: Make platform teardown callback return void", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel-sha204a - Mark OF related data as maybe unused", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - crypto: qat - fix restarting state leak on allocation failure", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - ALSA: seq: Avoid confusion of aligned read size", " - iio: imu: inv_mpu6050: fix frequency setting when chip is off", " - iio: invensense: fix odr switching to same value", " - ALSA: seq: Skip event type filtering for UMP events", " - ALSA: seq: Check UMP support for midi_version change", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - Linux 5.15.212", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72282", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72068", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64301", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64304", " - crypto: qat - validate RSA CRT component lengths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64593", " - btrfs: do not trim a device which is not writeable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64594", " - usb: gadget: f_fs: initialize reset_work at allocation time", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68456", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64329", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64352", " - bpf: Allow LPM map access from sleepable BPF programs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64355", " - bpf: Reject fragmented frames in devmap", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64361", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64363", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64371", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64364", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64375", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64390", " - ksmbd: track the connection owning a byte-range lock", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-31610", " - ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64380", " - smb: client: harden POSIX SID length parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64379", " - smb: client: mask server-provided mode to 07777 in modefromsid", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64401", " - smb: client: resolve SWN tcon from live registrations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64381", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64206", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64413", " - netfilter: ebtables: zero chainstack array", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64428", " - gpio: sch: use raw_spinlock_t in the irq startup path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64438", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64441", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64461", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64446", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64448", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64462", " - PCI: altera: Fix resource leaks on probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64475", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64488", " - ALSA: aoa: check snd_ctl_new1() return value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64510", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64512", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68466", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68467", " - mtd: mchp23k256: use SPI match data for chip caps", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68469", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68474", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68475", " - reset: sunxi: fix memory region leak on ioremap failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68478", " - memstick: ms_block: reject a card that reports too many blocks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68479", " - Bluetooth: btrtl: validate firmware patch bounds", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72004", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72005", " - wifi: rt2x00: avoid full teardown before work setup in probe", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72010", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72013", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72021", " - ipvs: use parsed transport offset in SCTP state lookup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72022", " - llc: fix SAP refcount leak in llc_ui_autobind()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72024", " - mac802154: remove interfaces with RCU list deletion", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72025", " - s390/monwriter: Reject buffer reuse with different data length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72036", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72038", " - net: liquidio: fix BAR resource leak on PF number failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72039", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72229", " - batman-adv: clean untagged VLAN on netdev registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72232", " - batman-adv: ensure minimal ethernet header on TX", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72235", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72047", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72048", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72049", " - ieee802154: admin-gate legacy LLSEC dump operations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72052", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72054", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72055", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72056", " - net: ena: clean up XDP TX queues when regular TX setup fails", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72061", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72066", " - cpu: hotplug: Bound hotplug states sysfs output", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72067", " - cpu: hotplug: Preserve per instance callback errors", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72074", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72076", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72078", " - Input: ims-pcu - validate control endpoint type", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72079", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72081", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72082", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72086", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72088", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72102", " - dm_early_create: fix freeing used table on dm_resume failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72105", " - dm-log: fix a bitset_size overflow on 32bit machines", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72107", " - dm era: fix out-of-bounds memory access for non-zero start sector", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72108", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72109", " - net: sparx5: unregister blocking notifier on init failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72120", " - can: bcm: add missing rcu list annotations and operations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72122", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72126", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72133", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72135", " - tpm: Make the TPM character devices non-seekable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72136", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72138", " - xen/gntdev: fix error handling in ioctl", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72140", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72153", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72159", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72160", " - ocfs2: reject dinodes with non-canonical i_mode type", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72163", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72164", " - ocfs2: avoid moving extents to occupied clusters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72165", " - mtd: rawnand: fix condition in 'nand_select_target()'", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72166", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72167", " - mtd: rawnand: pl353: fix probe resource allocation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72171", " - mtd: slram: remove failed entries from the device list", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72181", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72182", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72193", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64532", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64533", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72195", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72197", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72215", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72218", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72219", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72223", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72224", " - nvdimm/btt: Free arenas on btt_init() error paths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72225", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72228", " - batman-adv: frag: fix primary_if leak on failed linearization", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72230", " - batman-adv: frag: free unfragmentable packet", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72231", " - batman-adv: tt: avoid request storms during pending request", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72233", " - batman-adv: bla: reacquire gw address after skb realloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72238", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72240", " - mfd: sm501: Fix reference leak on failed device registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72241", " - leds: uleds: Fix potential buffer overread", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72245", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64554", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72247", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72250", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72256", " - netfilter: xt_cluster: reject template conntracks in hash match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72264", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72265", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72267", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72268", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72269", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72270", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72271", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72272", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72274", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72275", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72276", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72297", " - net: atm: reject out-of-range traffic classes in QoS validation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72298", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72306", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72307", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72310", " - smb: client: fix overflow in passthrough ioctl bounds check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72314", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72316", " - dm era: fix NULL pointer dereference in metadata_open()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72319", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72326", " - net/sched: cake: reject overhead values that underflow length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64549", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64550", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72347", " - netfilter: xt_connmark: reject invalid shift parameters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72349", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72350", " - netfilter: xt_u32: reject invalid shift counts", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72351", " - gue: validate REMCSUM private option length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64547", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72371", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72374", " - afs: Fix callback service message parsers to pass through -EAGAIN", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72378", " - afs: Fix error code in afs_extract_vl_addrs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72389", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64540", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72392", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72396", " - hwmon: adm1275: Prevent reading uninitialized stack", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72400", " - seg6: validate SRH length before reading fixed fields", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72406", " - net: sungem: fix probe error cleanup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72409", " - net: mvneta: re-enable percpu interrupt on resume", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72414", " - net: dsa: sja1105: round up PTP perout pin duration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64545", " - net, bpf: check master for NULL in xdp_master_redirect()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72418", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72421", " - ipv4: fib: Don't ignore error route in local/main tables.", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64538", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64546", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72428", " - bpf: Fix stack slot index in nospec checks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72433", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72435", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72441", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72447", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64553", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72448", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72450", " - xfrm: validate selector family and prefixlen during match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72459", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72460", " - apparmor: check label build before no_new_privs test", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72476", " - dmaengine: Fix possible use after free", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72479", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72481", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72483", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72484", " - staging: most: video: avoid double free on video register failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72489", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72492", " - ksmbd: fix use-after-free in same_client_has_lease()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72502", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74256", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64548", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74262", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74265", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74276", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74279", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74280", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74281", " - tipc: reject inverted service ranges from peer bindings", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74282", " - tipc: prevent snt_unacked underflow on CONN_ACK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74283", " - tipc: require net admin for TIPCv2 netlink mutators", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74284", " - net/sched: sch_hfsc: Don't make class passive twice", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74287", " - sctp: validate embedded address parameter length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64537", " - bridge: cfm: reject invalid CCM interval at configuration time", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74288", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74292", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74293", " - ASoC: fsl: fsl_audmix: Validate written enum values", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74295", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74297", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74305", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74312", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74313", " - vduse: hold vduse_lock across IDR lookup in open path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74320", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74321", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74327", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74329", " - watchdog: unregister PM notifier on watchdog unregister", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74330", " - configfs: fix lockless traversals of ->s_children", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74331", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74339", " - ALSA: seq: Clear variable event pointer on read", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74340", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74346", " - RDMA/irdma: Fix OOB read during CQ MR registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74348", " - ocfs2/dlm: require a ref for locking_state debugfs open", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74349", " - ocfs2: reject FITRIM ranges shorter than a cluster", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74351", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74359", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74363", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74379", " - dax/kmem: account for partial discontiguous resource upon removal", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74382", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74390", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74395", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74399", " - evm: terminate and bound the evm_xattrs read buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64544", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74402", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74408", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74410", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74416", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74424", " - fbcon: fix NULL pointer dereference for a console without vc_data", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74426", " - afs: fix NULL pointer dereference in afs_get_tree()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74438", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74578", " - crypto: algif_skcipher - force synchronous processing on trees without", " ctx->state", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64600", " - xfs: resample the data fork mapping after cycling ILOCK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64187", " - xfs: fail recovery on a committed log item with no regions", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64266", " - fuse: re-lock request before returning from fuse_ref_folio()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64268", " - RDMA/siw: bound Read Response placement to the RREAD length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64269", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64271", " - Input: touchwin - reset the packet index on every complete packet", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64273", " - Input: iforce - bound the device-reported force-feedback effect index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64274", " - Input: goodix - clamp the device-reported contact count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64275", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64276", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64277", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64279", " - i2c: core: fix adapter deregistration race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64604", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64296", " - exfat: bound uniname advance in exfat_find_dir_entry()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64298", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64299", " - tracing: Prevent out-of-bounds read in glob matching", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64303", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64306", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64312", " - crypto: pcrypt - restore callback for non-parallel fallback", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64313", " - crypto: ecc - Fix carry overflow in vli multiplication", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64315", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64315 // CVE-2026-64316", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64317", " - isofs: bound Rock Ridge symlink components to the SL record", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64318", " - partitions: aix: bound the pp_count scan to the ppe array", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64322", " - udf: validate sparing table length as an entry count, not a byte count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64323", " - udf: validate VAT header length against the VAT inode size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64324", " - udf: validate free block extents against the partition length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64330", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64331", " - usbip: vudc: fix NULL deref in vep_dequeue()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64332", " - USB: ulpi: fix memory leak on registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64333", " - USB: serial: digi_acceleport: fix write buffer corruption", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64334", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64335", " - USB: serial: digi_acceleport: fix broken rx after throttle", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64336", " - USB: serial: keyspan_pda: fix information leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64337", " - usb: mtu3: unmap request DMA on queue failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64338", " - USB: misc: uss720: unregister parport on probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64340", " - USB: legousbtower: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64342", " - USB: iowarrior: fix use-after-free on disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64343", " - USB: ldusb: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64344", " - USB: idmouse: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64346", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64347", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64350", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64351", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64359", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64360", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64362", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68091", " - HID: wacom: stop hardware after post-start probe failures", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64370", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64372", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64373", " - cpufreq: Fix hotplug-suspend race during reboot", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64374", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64403", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64408", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64411", " - netfilter: ebtables: terminate table name before find_table_lock()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64412", " - netfilter: ebtables: module names must be null-terminated", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64420", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64422", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64423", " - ipv4: igmp: remove multicast group from hash table on device destruction", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64425", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64429", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64430", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64432", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68090", " - debugobjects: Plug race against a concurrent OOM disable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64435", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64436", " - net: af_key: initialize alg_key_len for IPComp states", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64599", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64440", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64536", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64442", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64443", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64444", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64445", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64450", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64452", " - 6lowpan: fix NHC entry use-after-free on error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64454", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64455", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64456", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64189", " - netfilter: ipset: fix race between dump and ip_set_list resize", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64465", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64468", " - binder: fix UAF in binder_free_transaction()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64469", " - binder: fix UAF in binder_thread_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64470", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64471", " - Bluetooth: btusb: fix use-after-free on registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64478", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64483", " - ALSA: firewire: isight: bound the sample count to the packet payload", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64484", " - ALSA: es1938: check snd_ctl_new1() return value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64487", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64494", " - iio: light: gp2ap002: fix runtime PM leak on read error", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64495", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64496", " - iio: event: Fix event FIFO reset race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64497", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64602", " - iio: adc: spear: Initialize completion before requesting IRQ", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64500", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64503", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64504", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64505", " - usb: gadget: function: rndis: add length check for header", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68088", " - usb: gadget: function: rndis: add length check to response query", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53392", " - NFSv4/flexfiles: reject zero filehandle version count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53402", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63810", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68459", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68460", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63815", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63818", " - f2fs: validate orphan inode entry count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68461", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63829", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2022-3114", " - clk: imx: Add check for kcalloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64514", " - userfaultfd: gate must_wait writability check on pte_present()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53399", " - nfsd: release layout stid on setlease failure", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - drm: Remove plane hsub/vsub alignment requirement for core helpers", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - selftests: forwarding: lib: Add helpers for checksum handling", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_VENDOR to minimize PHY ID table", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - parport: Fix race between port and client registration", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - wireguard: send: append trailer after expanding head", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate VMBus packet size in receive callback", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - HID: pass the buffer size to hid_report_raw_event", " - HID: core: Fix size_t specifier in hid_report_raw_event()", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - serial: dz: Fix bootconsole handover lockup", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - USB: serial: mct_u232: fix memory corruption with small endpoint", " - compiler-clang.h: Add __diag infrastructure for clang", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", " - time: Fix off-by-one in settimeofday() usec validation", " - KVM: arm64: Remove VPIPT I-cache handling", " - arm64: tlb: Allow XZR argument to TLBI ops", " - arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBI", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", " - net: mv643xx: fix OF node refcount", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - SAUCE: Revert \"net/tcp-md5: Fix MAC comparison to be constant-time\"", " - f2fs: fix to do sanity check on dcc->discard_cmd_cnt conditionally", " - smb: server: fix max_connections off-by-one in tcp accept path", " - arm64/mm: Enable batched TLB flush in unmap_hotplug_range()", " - rtw88: 8821ce: Disable PCIe ASPM L1 for 8821CE using chip ID", " - ALSA: aoa: Use guard() for mutex locks", " - ALSA: aoa: i2sbus: clear stale prepared state", " - media: rc: ttusbir: respect DMA coherency rules", " - ALSA: aoa: Skip devices with no codecs in i2sbus_resume()", " - sched: Use u64 for bandwidth ratio calculations", " - ALSA: core: Fix potential data race at fasync handling", " - net: qrtr: ns: Change servers radix tree to xarray", " - net: mctp: fix don't require received header reserved bits to be zero", " - randomize_kstack: Maintain kstack_offset per task", " - mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration", " - mtd: spi-nor: sst: Fix write enable before AAI sequence", " - can: ucan: fix typos in comments", " - printk: add print_hex_dump_devel()", " - usb: typec: tcpm: reset internal port states on soft reset AMS", " - usb: dwc3: Move GUID programming after PHY initialization", " - net: ipv4: stop checking crypto_ahash_alignmask", " - net: ipv6: stop checking crypto_ahash_alignmask", " - spi: syncuacer: fix controller deregistration", " - spi: sun4i: fix controller deregistration", " - spi: spi-ti-qspi: Convert to platform remove callback returning void", " - spi: ti-qspi: fix controller deregistration", " - spi: zynq-qspi: fix controller deregistration", " - spi: sun6i: fix controller deregistration", " - spi: tegra114: fix controller deregistration", " - spi: tegra20-sflash: fix controller deregistration", " - spi: uniphier: fix controller deregistration", " - mm/hugetlb_cma: round up per_node before logging it", " - spi: topcliff-pch: Convert to platform remove callback returning void", " - spi: topcliff-pch: fix controller deregistration", " - tracing/probes: Limit size of event probe to 3K", " - SAUCE: Revert \"smb: client: validate dacloffset before building DACL", " pointers\"", " - smb: client: Use FullSessionKey for AES-256 encryption key derivation", " - mptcp: pm: prio: skip closed subflows", " - mptcp: pm: ADD_ADDR rtx: resched blocked ADD_ADDR quicker", " - f2fs: fix incorrect file address mapping when inline inode is unwritten", " - f2fs: fix false alarm of lockdep on cp_global_sem lock", " - spi: st-ssc4: fix controller deregistration", " - spi: lantiq-ssc: fix controller deregistration", " - genetlink: Use internal flags for multicast groups", " - smb: client: require net admin for CIFS SWN netlink", " - Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 2", " - Bluetooth: MGMT: validate Add Extended Advertising Data length", " - qed: Use the bitmap API to simplify some functions", " - qed: fix double free in qed_cxt_tables_alloc()", " - Bluetooth: Consolidate code around sk_alloc into a helper function", " - Bluetooth: Init sk_peer_* on bt_sock_alloc", " - net: hsr: defer node table free until after RCU readers", " - ice: fix VF queue configuration with low MTU values", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ioam: add NULL check for idev in ipv6_hop_ioam()", " - use less confusing names for iov_iter direction initializers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - selftests: mptcp: drop nanoseconds width specifier", " - mptcp: do not drop partial packets", " - octeontx2-af: CGX: add bounds check to cgx_speed_mbps index", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - spi: qup: switch to use modern name", " - spi: qup: fix error pointer deref after DMA setup failure", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - phy: tegra: xusb: Disable trk clk when not in use", " - phy: tegra: xusb: Fix per-pad high-speed termination calibration", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - serial: samsung_tty: Use port lock wrappers", " - tty: serial: samsung: use u32 for register interactions", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: gadget: f_hid: tidy error handling in hidg_alloc", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - serial: altera_jtaguart: Use platform_get_irq_optional() to get the", " interrupt", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - tty: serial: qcom-geni-serial: remove unused symbols", " - tty: serial: qcom-geni-serial: align #define values", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - batman-adv: tp_meter: fix tp_num leak on kmalloc failure", " - SAUCE: Revert \"net/ipv6: ioam6: prevent schema length wraparound in", " trace fill\"", " - SAUCE: Revert \"nfsd: fix heap overflow in NFSv4.0 LOCK replay cache\"", " - ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6", " - selinux: enable genfscon labeling for securityfs", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: close TOCTOU race while computing rcv_wnd", " - fbdev: vt8500lcdfb: Fix dma_free_coherent() cpu_addr parameter", " - SAUCE: Revert \"apparmor: validate DFA start states are in bounds in", " unpack_pdb\"", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: validate default DFA states are in bounds", " - media: rc: ttusbir: fix inverted error logic", " - batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown", " - media: rc: igorplugusb: fix control request setup packet", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - batman-adv: tp_meter: fix race condition in send error reporting", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - Linux 5.15.210", " - drm/v3d: Store the active job inside the queue's state", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: tt: prevent TVLV entry number overflow", " - vfio/iommu_type1: replace kfree with kvfree", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - i2c: stub: Reject I2C block transfers with invalid length", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", " - xhci: fix memory leak regression when freeing xhci vdev devices depth", " first", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", " - virtiofs: fix UAF on submount umount", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - Revert \"ptp: add testptp mask test\"", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", " - kselftest/arm64: signal: Skip SVE signal test if not enough VLs", " supported", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: v: prevent OGM aggregation on disabled hardif", " - batman-adv: tp_meter: restrict number of unacked list entries", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - ring-buffer: Remove ring_buffer_read_prepare_sync()", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", " - mac802154: llsec: add skb_cow_data() before in-place crypto", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", " - keys: Pin request_key_auth payload in instantiate paths", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: ath11k: fix warning when unbinding", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", " - bpf: use kvfree() for replaced sysctl write buffer", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", " - fpga: region: fix use-after-free in child_regions_with_firmware()", " - ocfs2: reject oversized group bitmap descriptors", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: fix posix_acl leak on SETACL decode failure", " - nfsd: check get_user() return when reading princhashlen", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", " - mptcp: fix missing wakeups in edge scenarios", " - hv: utils: handle and propagate errors in kvp_register", " - misc: fastrpc: Add dma_mask to fastrpc_channel_ctx", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - fuse: re-lock request before replacing page cache folio", " - ksmbd: reject non-VALID session in compound request branch", " - Documentation: ioctl-number: Extend \"Include File\" column width", " - crypto: qat - Replace kzalloc() + copy_from_user() with memdup_user()", " - crypto: qat - Return pointer directly in adf_ctl_alloc_resources", " - crypto: qat - remove unused character device and IOCTLs", " - Linux 5.15.211", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39931", " - crypto: af_alg - Set merge to zero early in af_alg_sendmsg", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31451", " - ext4: add bounds check for inline data length in ext4_read_inline_page", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43355", " - iio: light: bh1780: fix PM runtime leak on error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53139", " - drm/v3d: Skip CSD when it has zeroed workgroups", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31402", " - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-23364", " - ksmbd: Compare MACs in constant time", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43341", " - net/ipv6: ioam6: prevent schema length wraparound in trace fill", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46208", " - batman-adv: stop tp_meter sessions during mesh teardown", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2023-54271", " - blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed", " before init", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53189", " - mm/huge_memory: update file PMD counter before folio_put()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52918", " - Bluetooth: serialize accept_q access", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46160", " - btrfs: fix missing last_unlink_trans update when removing a directory", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46195", " - smb: client: validate dacloffset before building DACL pointers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46292", " - pmdomain: core: Fix detach procedure for virtual devices in genpd", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46159", " - btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to", " info-leak", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46191", " - fbcon: Avoid OOB font access if console rotation fails", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46116", " - xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46193", " - xfrm: ah: account for ESN high bits in async callbacks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46180", " - wifi: brcmfmac: Fix potential use-after-free issue when stopping", " watchdog task", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31709", " - smb: client: validate the whole DACL before rewriting it in cifsacl", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46196", " - tracepoint: balance regfunc() on func_add() failure in", " tracepoint_add_func()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46291", " - crypto: caam - guard HMAC key hex dumps in hash_digest_key", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46090", " - ALSA: aloop: Fix peer runtime UAF during format-change stop", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46052", " - ceph: only d_add() negative dentries when they are unhashed", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45999", " - erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46103", " - can: ucan: fix devres lifetime", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46056", " - Bluetooth: hci_event: fix potential UAF in SSP passkey handlers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46299", " - hfsplus: fix held lock freed on hfsplus_fill_super()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46169", " - hfsplus: fix uninit-value by validating catalog record size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45991", " - udf: fix partition descriptor append bookkeeping", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46065", " - fbdev: defio: Disconnect deferred I/O from the lifetime of struct", " fb_info", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46086", " - net: bridge: use a stable FDB dst snapshot in RCU readers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46003", " - net: qrtr: ns: Limit the total number of nodes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46038", " - net: qrtr: ns: Free the node during ctrl_cmd_bye()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46026", " - net: qrtr: ns: Limit the maximum number of lookups", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46091", " - media: rc: igorplugusb: heed coherency rules", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46078", " - erofs: fix the out-of-bounds nameoff handling for trailing dirents", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46069", " - wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46021", " - thermal: core: Fix thermal zone governor cleanup issues", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46092", " - wifi: rtw88: check for PCI upstream bridge existence", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31700", " - net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31712", " - ksmbd: require minimum ACE size in smb_check_perm_dacl()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31708", " - smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43350", " - smb: client: require a full NFS mode SID before reading mode bits", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31711", " - smb: server: fix active_num_conn leak on transport allocation failure", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31715", " - f2fs: fix UAF caused by decrementing sbi->nr_pages[] in", " f2fs_write_end_io()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43492", " - lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43383", " - net/tcp-md5: Fix MAC comparison to be constant-time", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52933", " - io_uring/poll: fix signed comparison in io_poll_get_ownership()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-22026", " - nfsd: don't ignore the return code of svc_proc_register()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2023-54125", " - fs/ntfs3: Return error for inconsistent extended attributes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31449", " - ext4: validate p_idx bounds in ext4_ext_correct_indexes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39929", " - smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45852", " - Revert \"RDMA/rxe: Fix double free in rxe_srq_from_init\"", " - RDMA/rxe: Fix double free in rxe_srq_from_init", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39863", " - wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info", " work", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43064", " - dmaengine: idxd: Fix not releasing workqueue on .release()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", " * CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", " * CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", " * CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Set CONFIG_ARM64_ERRATUM_4118414=y", " * CVE-2025-10263", " - arm64: cputype: Add C1-Premium definitions", " - arm64: cputype: Add C1-Ultra definitions", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", " * SAUCE: Revert erroneous application of \"netfilter: nf_tables: fix inverted", " genmask check in nft_map_catchall_activate()\" (LP: #2164800)", " - SAUCE: Revert \"netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()\"", "" ], "package": "linux-kvm", "version": "5.15.0-1109.114", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2165588, 2166457, 1786013, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2163508, 2164699, 1961566, 1956562, 2164516, 2137199, 2165170, 2165170, 2165166, 2165125, 2165125, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2164800 ], "author": "Thibault Ferrante ", "date": "Thu, 10 Sep 2026 15:20:26 +0200" } ], "notes": "linux-headers-5.15.0-1109-kvm version '5.15.0-1109.114' (source package linux-kvm version '5.15.0-1109.114') was added. linux-headers-5.15.0-1109-kvm version '5.15.0-1109.114' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1108-kvm. As such we can use the source package version of the removed package, '5.15.0-1108.113', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-image-5.15.0-1109-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1108.113", "version": null }, "to_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1109.114", "version": "5.15.0-1109.114" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 5.15.0-1109.114", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed-kvm", "version": "5.15.0-1109.114", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 1786013 ], "author": "Thibault Ferrante ", "date": "Thu, 10 Sep 2026 16:08:22 +0200" } ], "notes": "linux-image-5.15.0-1109-kvm version '5.15.0-1109.114' (source package linux-signed-kvm version '5.15.0-1109.114') was added. linux-image-5.15.0-1109-kvm version '5.15.0-1109.114' has the same source package name, linux-signed-kvm, as removed package linux-image-5.15.0-1108-kvm. As such we can use the source package version of the removed package, '5.15.0-1108.113', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-kvm-headers-5.15.0-1109", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": "5.15.0-1109.114" }, "cves": [ { "cve": "CVE-2026-64582", "url": "https://ubuntu.com/security/CVE-2026-64582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix a use-after-free problem in rxe_mmap rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1: list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */ ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */ [...] rxe_vma_open(vma); /* kref_get, ref → 2 */ remap_vmalloc_range_partial() walks PTEs without any lock. A concurrent DESTROY_CQ ioctl on another CPU calls: kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */ vfree(ip->obj) /* clears vmalloc PTEs mid-walk */ kfree(ip) /* frees rxe_mmap_info */ This yields: 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF. It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get). The call trace are as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:validate_page_before_insert+0x32/0x300 Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5 RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00 R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20 FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0 Call Trace: insert_page+0x8f/0x190 ? __pfx_insert_page+0x10/0x10 ? kasan_save_alloc_info+0x38/0x60 vm_insert_page+0x2e7/0x400 remap_vmalloc_range_partial+0x212/0x3e0 remap_vmalloc_range+0x6e/0xb0 ? __kasan_check_write+0x14/0x30 rxe_mmap+0x2e9/0x5d0 ib_uverbs_mmap+0x1ad/0x2c0 __mmap_region+0x12c2/0x2ad0 ? __pfx___mmap_region+0x10/0x10 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_prev_slot+0x360/0x39c0 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_next_slot+0x1e5b/0x2f40 ? __sanitizer_cov_trace_cmp8+0x18/0x30 ? unmapped_area_topdown+0x4dd/0x610 ? kfree+0x1b1/0x440 ? free_cpumask_var+0x16/0x30 ? __kasan_slab_free+0x7d/0xa0 ? __sanitizer_cov_trace_cmp8+0x18/0x30 mmap_region+0x2e6/0x3c0 do_mmap+0xa3e/0x12a0 ? __pfx_do_mmap+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? down_write_killable+0xba/0x160 ? __pfx_down_write_killable+0x10/0x10 ? __sanitizer_cov_trace_cmp4+0x16/0x30 vm_mmap_pgoff+0x2d4/0x4a0 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x1bf/0x270 ksys_mmap_pgoff+0x40c/0x690 ? __sanitizer_cov_trace_const_cmp4+0x16/0x30 ? __pfx_ksys_mmap_pgoff+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? _raw_spin_trylock+0xbb/0x130 ? __pfx__raw_spin_trylock+0x10/0x10 __x64_sys_mmap+0x135/0x1e0 x64_sys_c ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-05 12:18:00 UTC" }, { "cve": "CVE-2026-74468", "url": "https://ubuntu.com/security/CVE-2026-74468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 (\"gpio: sch: use raw_spinlock_t in the irq startup path\") and commit 90f0109019e6 (\"gpio: eic-sprd: use raw_spinlock_t in the irq startup path\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74482", "url": "https://ubuntu.com/security/CVE-2026-74482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74443", "url": "https://ubuntu.com/security/CVE-2026-74443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at \t(unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74444", "url": "https://ubuntu.com/security/CVE-2026-74444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes \tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74453", "url": "https://ubuntu.com/security/CVE-2026-74453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the \"Auto-initialise Tile State Data Array\" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74455", "url": "https://ubuntu.com/security/CVE-2026-74455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: validate uCAN receive record lengths pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74456", "url": "https://ubuntu.com/security/CVE-2026-74456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 (\"net: usb: lan78xx: Fix double free issue with interrupt buffer allocation\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74457", "url": "https://ubuntu.com/security/CVE-2026-74457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74458", "url": "https://ubuntu.com/security/CVE-2026-74458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74459", "url": "https://ubuntu.com/security/CVE-2026-74459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74460", "url": "https://ubuntu.com/security/CVE-2026-74460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74461", "url": "https://ubuntu.com/security/CVE-2026-74461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74463", "url": "https://ubuntu.com/security/CVE-2026-74463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74464", "url": "https://ubuntu.com/security/CVE-2026-74464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74465", "url": "https://ubuntu.com/security/CVE-2026-74465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the \"hash\" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68451", "url": "https://ubuntu.com/security/CVE-2026-68451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA ECC private key requests cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "high", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68452", "url": "https://ubuntu.com/security/CVE-2026-68452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-74467", "url": "https://ubuntu.com/security/CVE-2026-74467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Check CAP_NET_ADMIN for private ioctls Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74469", "url": "https://ubuntu.com/security/CVE-2026-74469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74471", "url": "https://ubuntu.com/security/CVE-2026-74471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Check return value of __register_event() in trace_module_add_events() trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74473", "url": "https://ubuntu.com/security/CVE-2026-74473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74475", "url": "https://ubuntu.com/security/CVE-2026-74475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74478", "url": "https://ubuntu.com/security/CVE-2026-74478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: vector: fix use-after-free in vector_mmsg_rx() When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: \tif (header_check < 0) { \t\tdev_kfree_skb_irq(skb); \t\tvp->estats.rx_encaps_errors++; \t\tcontinue; \t} The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: \t(*skbuff_vector) = NULL; \tmmsg_vector++; \tskbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74480", "url": "https://ubuntu.com/security/CVE-2026-74480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74481", "url": "https://ubuntu.com/security/CVE-2026-74481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74485", "url": "https://ubuntu.com/security/CVE-2026-74485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: reject a flag character as the field delimiter The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: \tmemset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering \tPaPEPPxPPiP with 'P' as the delimiter (name \"a\", type extension, magic \"x\", interpreter \"i\", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74488", "url": "https://ubuntu.com/security/CVE-2026-74488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: \trx_skb = __skb_dequeue(&list); \trx_hdr = (struct rx_packet_hdr *)rx_skb->data; \tif (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && \t ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { \t\tmwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, \t\t\t\t\t\t skb->len); \t} The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with \tif (!reuse_skb) \t\tdev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes \ties_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, \tfor (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { \t\tu8 ie_len = pos[1]; \t\tif (pos + 2 + ie_len > end) \t\t\tbreak; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74490", "url": "https://ubuntu.com/security/CVE-2026-74490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74492", "url": "https://ubuntu.com/security/CVE-2026-74492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: do not update comments from kernel-side hash adds mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74493", "url": "https://ubuntu.com/security/CVE-2026-74493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket use-after-free during link group termination __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74495", "url": "https://ubuntu.com/security/CVE-2026-74495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74497", "url": "https://ubuntu.com/security/CVE-2026-74497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74498", "url": "https://ubuntu.com/security/CVE-2026-74498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74499", "url": "https://ubuntu.com/security/CVE-2026-74499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() snd_usbmidi_akai_output() computes its fill-loop bound \tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74505", "url": "https://ubuntu.com/security/CVE-2026-74505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74507", "url": "https://ubuntu.com/security/CVE-2026-74507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74508", "url": "https://ubuntu.com/security/CVE-2026-74508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74512", "url": "https://ubuntu.com/security/CVE-2026-74512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74518", "url": "https://ubuntu.com/security/CVE-2026-74518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocate_file_region_entries() allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74519", "url": "https://ubuntu.com/security/CVE-2026-74519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-74523", "url": "https://ubuntu.com/security/CVE-2026-74523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74525", "url": "https://ubuntu.com/security/CVE-2026-74525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: free TX rings on RX allocation failure When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74540", "url": "https://ubuntu.com/security/CVE-2026-74540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74546", "url": "https://ubuntu.com/security/CVE-2026-74546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74547", "url": "https://ubuntu.com/security/CVE-2026-74547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74548", "url": "https://ubuntu.com/security/CVE-2026-74548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix UAF of txrx_stats in nv_remove nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74549", "url": "https://ubuntu.com/security/CVE-2026-74549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74556", "url": "https://ubuntu.com/security/CVE-2026-74556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74557", "url": "https://ubuntu.com/security/CVE-2026-74557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: \tsenselen = get_unaligned_be16(data); \tif (datalen < senselen) \t\tgoto invalid_datalen; \tmemcpy(sc->sense_buffer, data + 2, \t min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74563", "url": "https://ubuntu.com/security/CVE-2026-74563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74579", "url": "https://ubuntu.com/security/CVE-2026-74579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes.", "cve_priority": "medium", "cve_public_date": "2026-08-17 06:19:00 UTC" }, { "cve": "CVE-2026-74564", "url": "https://ubuntu.com/security/CVE-2026-74564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74566", "url": "https://ubuntu.com/security/CVE-2026-74566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: make keyring key-chunk byte order agree with keyring_diff_objects() keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74567", "url": "https://ubuntu.com/security/CVE-2026-74567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74569", "url": "https://ubuntu.com/security/CVE-2026-74569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and \"datalen = datalen + diff - msglen\" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-43491", "url": "https://ubuntu.com/security/CVE-2026-43491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-74577", "url": "https://ubuntu.com/security/CVE-2026-74577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: \tr = nlmsg_data(nlh); \tr->rtm_family\t = AF_MPLS; \tr->rtm_dst_len\t= 20; \tr->rtm_src_len\t= 0; \tr->rtm_table\t= RT_TABLE_MAIN; \tr->rtm_type\t= RTN_UNICAST; \tr->rtm_scope\t= RT_SCOPE_UNIVERSE; \tr->rtm_protocol = rt->rt_protocol; \tr->rtm_flags\t= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64543", "url": "https://ubuntu.com/security/CVE-2026-64543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix use-after-free of the discoverer in tipc_disc_rcv() bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(), but tipc_disc_rcv() still dereferences b->disc in RX softirq under rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv). L2 bearers are safe thanks to the synchronize_net() in tipc_disable_l2_media(), but the UDP bearer defers that call to the cleanup_bearer() workqueue, so the discoverer is freed with no grace period: BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149) Read of size 8 at addr ffff88802348b728 by task poc_tipc/184 tipc_disc_rcv (net/tipc/discover.c:149) tipc_rcv (net/tipc/node.c:2126) tipc_udp_recv (net/tipc/udp_media.c:391) udp_rcv (net/ipv4/udp.c:2643) ip_local_deliver_finish (net/ipv4/ip_input.c:241) Freed by task 181: kfree (mm/slub.c:6565) bearer_disable (net/tipc/bearer.c:418) tipc_nl_bearer_disable (net/tipc/bearer.c:1001) The bearer is freed with kfree_rcu(); free the discoverer the same way. Add an rcu_head to struct tipc_discoverer and free it and its skb from an RCU callback. Because the RCU callback (tipc_disc_free_rcu) lives in module text, a call_rcu() that is still pending when the tipc module is unloaded would invoke a freed function. Add an rcu_barrier() to tipc_exit() after the bearer subsystem has been torn down, so all pending discoverer callbacks have run before the module text goes away. Reachable from an unprivileged user namespace: the TIPCv2 genl family is netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC and CONFIG_TIPC_MEDIA_UDP.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72123", "url": "https://ubuntu.com/security/CVE-2026-72123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 (\"can: bcm: use call_rcu() instead of costly synchronize_rcu()\") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a \"scheduling while atomic\" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72019", "url": "https://ubuntu.com/security/CVE-2026-72019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d (\"macvlan: do not assume mac_header is set in macvlan_broadcast()\") for exactly this purpose.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-52977", "url": "https://ubuntu.com/security/CVE-2026-52977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-72282", "url": "https://ubuntu.com/security/CVE-2026-72282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72068", "url": "https://ubuntu.com/security/CVE-2026-72068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64301", "url": "https://ubuntu.com/security/CVE-2026-64301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error path where process_scmi_regulator_of_node() fails, the function returns without calling of_node_put() on the child node, leaking the reference. Add of_node_put(np) on the error path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64304", "url": "https://ubuntu.com/security/CVE-2026-64304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - validate RSA CRT component lengths The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64593", "url": "https://ubuntu.com/security/CVE-2026-64593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not trim a device which is not writeable [BUG] There is a bug report that btrfs/242 can randomly fail with the following NULL pointer dereference: run fstests btrfs/242 at 2026-06-01 10:25:08 BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609) BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874 BTRFS info (device sdc): using crc32c checksum algorithm BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS info (device sdc): allowing degraded mounts BTRFS info (device sdc): turning on async discard BTRFS info (device sdc): enabling free space tree Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000 CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_trim_fs+0x34c/0xa00 [btrfs] lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs] Call trace: btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P) btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] __arm64_sys_ioctl+0xac/0x108 invoke_syscall.constprop.0+0x5c/0xd0 el0_svc_common.constprop.0+0x40/0xf0 do_el0_svc+0x24/0x40 el0_svc+0x40/0x1d0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00) ---[ end trace 0000000000000000 ]--- Also the reporter is very kind to test the following ASSERT() added to btrfs_trim_free_extents_throttle(): \tASSERT(device->bdev, \t \"devid=%llu path=%s dev_state=0x%lx\\n\", \t device->devid, btrfs_dev_name(device), device->dev_state); And it shows the following output: assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82) Which means the device->bdev is NULL, and the dev_state is BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without BTRFS_DEV_STATE_WRITEABLE flag set. [CAUSE] The pc points to the following call chain: btrfs_trim_fs() |- btrfs_trim_free_extents() |- btrfs_trim_free_extents_throttle() |- bdev_max_discard_sectors(device->bdev) So the NULL pointer dereference is caused by device->bdev being NULL. This looks impossible by a quick glance, as just before calling btrfs_trim_free_extents_throttle(), we have skipped any device that has BTRFS_DEV_STATE_MISSING flag set. However in this particular case, there is a window where the missing device is later re-scanned, causing btrfs to remove the BTRFS_DEV_STATE_MISSING flag: btrfs_control_ioctl() |- btrfs_scan_one_device() |- device_list_add() |- rcu_assign_pointer(device->name, name); | This updates the missing device's path to the new good path. | |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state) This removes the BTRFS_DEV_STATE_MISSING flag. This allows the missing device to re-appear and clear the BTRFS_DEV_STATE_MISSING flag. However the device still does not have the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated. The bdev pointer remains NULL, triggering the crash later. [FIX] This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and device->bdev pointer, and shows a gap in btrfs's re-appearing-device handling. The proper handling of re-appearing device will need quite some extra work, which is out of the context of this small ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64594", "url": "https://ubuntu.com/security/CVE-2026-64594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: initialize reset_work at allocation time ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on ffs->reset_work when a functionfs instance is unmounted: \tffs_data_reset(ffs); \tcancel_work_sync(&ffs->reset_work); However ffs->reset_work is only ever initialized via INIT_WORK() in ffs_func_set_alt() and ffs_func_disable(), and only on the FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed() when the instance is mounted with the \"no_disconnect\" option, so for the common case (no \"no_disconnect\", or mounted and unmounted without ever being deactivated) reset_work is never initialized. ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch it either, so reset_work.func is left NULL. cancel_work_sync() on such a work then trips the WARN_ON(!work->func) guard in __flush_work(): WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flush_work cancel_work_sync ffs_fs_kill_sb [usb_f_fs] deactivate_locked_super deactivate_super cleanup_mnt __cleanup_mnt task_work_run exit_to_user_mode_loop el0_svc On older kernels cancel_work_sync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization. Initialize reset_work once in ffs_data_new() so it is always valid for the lifetime of the ffs_data, and drop the now-redundant INIT_WORK() calls from the two deactivation paths.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68456", "url": "https://ubuntu.com/security/CVE-2026-68456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect() ueagle-atm uses the asynchronous request_firmware_nowait() in .probe(), but does not wait for its completion, not even in .disconnect(); so, if the device is unplugged meanwhile, its teardown runs concurrently with that. Even though this inconsistency is worth addressing on its own, it has also triggered several bug reports in syzbot over the years (some auto-closed) where the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER) creates a firmware subdirectory in the device directory during its removal, which might hit unexpected conditions in kernfs, apparently, depending at which point the add and remove operations raced. (See links.) The pattern is: usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2 usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw Call trace: ... kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs _request_firmware request_firmware_work_func ... (Some variations are observed, after fw_load_sysfs_fallback(), e.g., [1].) While the kernfs side is being looked at, the ueagle-atm side can be fixed by waiting for the pre-firmware load in the .disconnect() handler. This change has a similar approach to previous work by Andrey Tsygunka [2] (wait_for_completion() in .disconnect()), but it is relatively different in design/implementation; using the Originally-by tag for credit assignment. This has been tested with: - synthetic reproducer to check the error path; - USB gadget (virtual device) to check the firmware upload path; - QEMU device emulator to check the device ID re-enumeration path; (The latter two were written by Claude; no other code/text in this commit.) Links (year first reported): 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd4 2024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84d86f0d71394829df6fc53daf6642c045983881 2021 https://syzbot.org/bug?id=3302dc1c0e2b9c94f2e8edb404eabc9267bc6f90 [1] https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 [2] https://lore.kernel.org/lkml/20250410093146.3776801-2-aitsygunka@yandex.ru/", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-64329", "url": "https://ubuntu.com/security/CVE-2026-64329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled. The probe error path already orders free_irq() before ucsi_destroy(). This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64352", "url": "https://ubuntu.com/security/CVE-2026-64352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to \"c || rcu_read_lock_held()\", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64355", "url": "https://ubuntu.com/security/CVE-2026-64355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject fragmented frames in devmap Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64361", "url": "https://ubuntu.com/security/CVE-2026-64361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length check_and_correct_requested_length() compares (off + len) against node_size using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfs_brec_remove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail. For example, with off=14 and len=0xFFFFFFF2 (underflowed from data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6, which is less than a typical node_size of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer. Fix this by widening the addition to u64 before comparing against node_size. This prevents the u32 wrap while keeping the logic straightforward.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64363", "url": "https://ubuntu.com/security/CVE-2026-64363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: appleir: fix UAF on pending key_up_timer in remove() appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 (\"HID: appletb-kbd: fix UAF in inactivity-timer cleanup path\") and has been present since the driver was introduced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64371", "url": "https://ubuntu.com/security/CVE-2026-64371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (part 1) Fix the easy cases where procfs currently calls ptrace_may_access() without exec_update_lock protection, where the fix is to simply add the extra lock or use mm_access(): - do_task_stat(): grab exec_update_lock - proc_pid_wchan(): grab exec_update_lock - proc_map_files_lookup(): use mm_access() instead of get_task_mm() - proc_map_files_readdir(): use mm_access() instead of get_task_mm() - proc_ns_get_link(): grab exec_update_lock - proc_ns_readlink(): grab exec_update_lock", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64364", "url": "https://ubuntu.com/security/CVE-2026-64364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix out-of-bounds bit access on mt_io_flags mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG. As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs \tfor (i = 0; i < mt->num_slots; i++) \t\tclear_bit(i, &td->mt_io_flags); with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received). The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required. Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two \"mt_io_flags & MT_IO_SLOTS_MASK\" arming checks become bitmap_empty(td->active_slots, td->maxcontacts). Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64375", "url": "https://ubuntu.com/security/CVE-2026-64375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (FD links) proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways. To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link().", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64390", "url": "https://ubuntu.com/security/CVE-2026-64390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: track the connection owning a byte-range lock SMB2_LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llist_lock. With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbd_lock and struct file_lock objects. Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llist_lock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-31610", "url": "https://ubuntu.com/security/CVE-2026-31610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: \tif (conn->use_spnego && conn->mechToken) { \t\tkfree(conn->mechToken); \t\tconn->mechToken = NULL; \t} so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-64380", "url": "https://ubuntu.com/security/CVE-2026-64380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: harden POSIX SID length parsing posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64379", "url": "https://ubuntu.com/security/CVE-2026-64379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: mask server-provided mode to 07777 in modefromsid When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64401", "url": "https://ubuntu.com/security/CVE-2026-64401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: resolve SWN tcon from live registrations cifs_swn_notify() looks up a witness registration by id under cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifs_get_swn_reg() lets multiple tcons for the same net/share name share one registration id. A same-share second mount can keep the cifs_swn_reg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tc_lock or incrementing tc_count through swnreg->tcon only moves the use-after-free earlier. Taking tc_lock while holding cifs_swnreg_idr_mutex also violates the documented CIFS lock order. Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifs_tcp_ses_lock -> tc_lock order. The notification path uses that pinned tcon directly and drops the reference when done. Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifs_swn_unregister() while the registration is still protected by cifs_swnreg_idr_mutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings. This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENT_MOVE ordering for the representative tcon because the old-IP unregister is sent before cifs_swn_register() sends the new-IP register.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64381", "url": "https://ubuntu.com/security/CVE-2026-64381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix next buffer leak in receive_encrypted_standard() receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64206", "url": "https://ubuntu.com/security/CVE-2026-64206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64413", "url": "https://ubuntu.com/security/CVE-2026-64413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: zero chainstack array sashiko reports: looking at ebtables table translation, could a sparse cpu_possible_mask lead to an uninitialized pointer free? If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1]. Not a real-world bug, such allocation isn't expected to fail in the first place.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64428", "url": "https://ubuntu.com/security/CVE-2026-64428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: sch: use raw_spinlock_t in the irq startup path sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64438", "url": "https://ubuntu.com/security/CVE-2026-64438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix VF2PF work teardown race in adf_disable_sriov() The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adf_accel_vf_info). Currently, adf_disable_sriov() destroys per-VF mutexes and frees vf_info without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory. This manifests as a use-after-free when KASAN is enabled: BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] Call Trace: kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vf_info is destroyed. Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64441", "url": "https://ubuntu.com/security/CVE-2026-64441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr() Three IE/attribute parsing functions have missing bounds checks. rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtw_get_sec_ie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain. rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at entry, before verifying that wps_ielen is large enough to contain the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside the attribute loop, get_unaligned_be16() is called on attr_ptr and attr_ptr+2 without checking that 4 bytes remain in the buffer. Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie() and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum IE length requirement, add a wps_ielen < 6 early return in rtw_get_wps_attr(), and add a 4-byte bounds check in its inner loop.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64461", "url": "https://ubuntu.com/security/CVE-2026-64461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64446", "url": "https://ubuntu.com/security/CVE-2026-64446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie() supplicant_ie is a 256-byte array in struct security_priv. The WPA and WPA2 IE copy paths use: memcpy(padapter->securitypriv.supplicant_ie, &pwpa[0], wpa_ielen + 2); where wpa_ielen is the raw IE length field (u8, 0-255). When a local user supplies a connect request via nl80211 with a crafted WPA IE of length 255, wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into the adjacent last_mic_err_time field. rtw_parse_wpa_ie() does not prevent this: its length consistency check compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255 when wpa_ie_len = 257, so the check passes silently. Add explicit bounds checks for both the WPA and WPA2 paths before the memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the supplicant_ie buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64448", "url": "https://ubuntu.com/security/CVE-2026-64448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: restrict implied bcc[0] exemption to responses without data area smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received (\"server can return one byte more due to implied bcc[0]\"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, yet smb2_check_message() still accepts it. The subsequent decoder then reads past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server; both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders are affected: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00 Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81 CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 asn1_ber_decoder+0x16a7/0x1b00 decode_negTokenInit+0x19/0x30 SMB2_negotiate+0x31d9/0x4c90 cifs_negotiate_protocol+0x1f2/0x3f0 cifs_get_smb_ses+0x93f/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 85: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 0 bytes to the right of allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0) which belongs to the cache cifs_small_rq of size 448 BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50 Read of size 329 at addr ffff88800726c678 by task mount.cifs/89 CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x36/0x50 decode_ntlmssp_challenge+0x457/0x680 SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0 SMB2_sess_setup+0x219/0x4f0 cifs_setup_session+0x248/0xaf0 cifs_get_smb_ses+0xf79/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 93: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 120 bytes inside of allocated 448-byte region [ffff88800726c600, ffff88800726c7c0) which belongs to the cache cifs_small_rq of size 448 Restrict the +1 exemption to responses that have no data area, so that it still covers the bcc[0] omission it was meant for. When a data area is present, the +1 discrepancy instead means the reported data length overruns the ---truncated---", "cve_priority": "negligible", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64462", "url": "https://ubuntu.com/security/CVE-2026-64462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64475", "url": "https://ubuntu.com/security/CVE-2026-64475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Release the VGA arbiter client on register_device() failure The re-order in the Fixes commit below displaced vfio_pci_vga_init() as the last failure point of what is now vfio_pci_core_register_device() without introducing an unwind for the VGA arbiter registration. In current kernels this is mostly benign because vfio_pci_set_decode() only uses pci_dev state, but the original failure path could leave a callback with a freed vdev cookie. The stale registration also becomes unsafe again once the callback follows drvdata to the vfio device. Add the required VGA unwind callout.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64488", "url": "https://ubuntu.com/security/CVE-2026-64488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return early if any fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64510", "url": "https://ubuntu.com/security/CVE-2026-64510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64512", "url": "https://ubuntu.com/security/CVE-2026-64512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Suppress UBSAN warning caused by field misuse The definition of reg->access_width changes depending on the reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses access_width to indicate the PCC region, which can result in a UBSAN if the value is greater than 4. For example: UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9 shift exponent 32 is too large for 32-bit type 'int' CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy) Hardware name: To be filled by O.E.M. Call trace: ...(trimming) ubsan_epilogue+0x10/0x48 __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ... (trimming) Lets fix this by validating the region type, as well as whether access_width has a value. Then since we are returning bit_width directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting the size.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68466", "url": "https://ubuntu.com/security/CVE-2026-68466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68467", "url": "https://ubuntu.com/security/CVE-2026-68467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mchp23k256: use SPI match data for chip caps The driver stores chip capacity information in both the OF match table and the SPI id table. Probe currently uses of_device_get_match_data(), so a non-OF SPI modalias match falls back to mchp23k256_caps even when the SPI id table selected a different part. Use spi_get_device_match_data() so SPI id-table driver_data is consumed when OF match data is absent. This keeps the existing default fallback while avoiding the wrong MTD geometry for id-table-only matches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68469", "url": "https://ubuntu.com/security/CVE-2026-68469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix permanently busy scans after multiple roam iterations In order for the firmware to sleep, the driver has to confirm a previously received sleep request. The normal sequence of evets goes like this: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Before sending the sleep-confirm command, the driver must make sure there are no commands either running or waiting to be completed. mwifiex_ret_802_11_associate() unconditionally sets ps_state = PS_STATE_AWAKE when it processes the association command response, outside of the normal powersave management flow. If EVENT_SLEEP arrives while the association command is in flight, ps_state is PRE_SLEEP when the association command response is parsed, and the forced AWAKE overwrites it. The deferred sleep-confirm is never sent. A subsequent scan_start command is correctly acknowledged, but the firmware doesn't generate scan_result events. The scan request never finishes, and additional requests from userspace fail with -EBUSY. After testing on both IW412 and W8997, I could only trigger the bug on the IW412 and observed the firmwares behave differently. On the IW412 the firmware still sends EVENT_SLEEP while the authentication / association process is ongoing. A W8997 under the same conditions seems to suppress power-save for the duration of the association, so PRE_SLEEP never coincided with the association response even after extended periods of testing using the loops described below (>12hours). On the IW412, the delay between commands that triggers an EVENT_SLEEP was empirically determined to be ~20ms. This delay can naturally occur when the driver is outputting debugging information (debug_mask = 0x00000037), in which situation the busy scans issue is repeatable while running \"test 1)\" as described below. If the delay between commands is less than ~20ms, the firmware stays awake and the issue was not reproducible running the same test. The host_mlme=false path also behaves differently. In this case, the entire authentication / association transaction is executed by one command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit EVENT_SLEEP while the command is running. Remove the assignment so the ps_state is only manipulated in the paths that are related to powersave event handling and on the main workqueue for correct sleep confirmation. The following loop tests were performed (with debugging output enabled): 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations. Each test ran in each device for at least 3 hours.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68474", "url": "https://ubuntu.com/security/CVE-2026-68474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access() spufs_mem_mmap_access() computes the local store offset as address - vma->vm_start, but bounds-checks it against vma->vm_end instead of the local store size. On 64-bit, offset is always well below vma->vm_end, so the clamp never fires and len stays unbounded against the LS_SIZE buffer returned by ctx->ops->get_ls(). Reject offsets at or beyond LS_SIZE and clamp len to the remaining space, mirroring the guard already used by spufs_mem_mmap_fault() and spufs_ps_fault().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68475", "url": "https://ubuntu.com/security/CVE-2026-68475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: reset: sunxi: fix memory region leak on ioremap failure In sunxi_reset_init(), when ioremap() fails, the memory region obtained via request_mem_region() is not released, leading to a resource leak. Add an err_mem_region label to properly release the memory region before freeing the data structure.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68478", "url": "https://ubuntu.com/security/CVE-2026-68478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memstick: ms_block: reject a card that reports too many blocks msb_ftl_initialize() computes the zone count from the card block count with no bound: \tmsb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; \t... \tfor (i = 0; i < msb->zone_count; i++) \t\tmsb->free_block_count[i] = MS_BLOCKS_IN_ZONE; msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the init loop past the end too. A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68479", "url": "https://ubuntu.com/security/CVE-2026-68479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: validate firmware patch bounds rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup. The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72004", "url": "https://ubuntu.com/security/CVE-2026-72004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix memory leak in ieee80211_register_hw() If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl. Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72005", "url": "https://ubuntu.com/security/CVE-2026-72005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: avoid full teardown before work setup in probe rt2x00lib_probe_dev() uses the full rt2x00lib_remove_dev() teardown for all probe failures. However, drv_data allocation and workqueue allocation can fail before intf_work, autowakeup_work and sleep_work have been initialized. Do not enter the full remove path until the probe has reached the point where those work items are set up. Return directly for drv_data allocation failure, and use a small early cleanup path for workqueue allocation failure. This issue was found by our static analysis tool and then confirmed by manual review of rt2x00lib_probe_dev() and rt2x00lib_remove_dev(). The early probe exits should not call a common teardown path that assumes the later work setup has already completed. A QEMU PoC forced alloc_ordered_workqueue() to fail before the work initializers are reached. The resulting fail path entered rt2x00lib_remove_dev(), and DEBUG_OBJECTS reported invalid work drains with rt2x00lib_probe_dev() and rt2x00lib_remove_dev() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72010", "url": "https://ubuntu.com/security/CVE-2026-72010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72013", "url": "https://ubuntu.com/security/CVE-2026-72013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent NULL pointer dereference in machine_kexec_prepare() A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72021", "url": "https://ubuntu.com/security/CVE-2026-72021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in SCTP state lookup set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header. This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed. Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72022", "url": "https://ubuntu.com/security/CVE-2026-72022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: llc: fix SAP refcount leak in llc_ui_autobind() llc_ui_autobind() opens a SAP after choosing a dynamic LSAP. llc_sap_open() returns a reference owned by the caller, and llc_sap_add_socket() takes a second reference for the socket's membership in the SAP hash tables. llc_ui_bind() drops the caller's reference after adding the socket, but llc_ui_autobind() keeps it. When the socket is closed, llc_sap_remove_socket() releases only the socket reference, leaving the SAP on llc_sap_list with sk_count == 0. This is user-visible because repeated autobind and close cycles can consume all dynamic SAP values and make later autobinds fail with -EUSERS. Drop the caller's reference after a successful autobind, matching llc_ui_bind()'s ownership model.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72024", "url": "https://ubuntu.com/security/CVE-2026-72024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: remove interfaces with RCU list deletion Queue wake, stop, and disable paths walk local->interfaces under RCU. The bulk hardware teardown path removes entries with list_del(), so an asynchronous transmit completion can follow a poisoned list node in ieee802154_wake_queue(). Use list_del_rcu() as in the single-interface removal path. The following unregister_netdevice() waits for in-flight RCU readers before freeing the netdevice, so no separate grace-period wait is needed.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72025", "url": "https://ubuntu.com/security/CVE-2026-72025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/monwriter: Reject buffer reuse with different data length When data buffers are reused, e.g. for interval sample records, the first record determines the data length, and the size of the buffer for user copy. Current monwriter code does not check if the data length was changed for subsequent records, which also would never happen for valid user programs. However, a malicious user could change the data length, resulting in out of bounds user copy to the kernel buffer, and memory corruption. By default, the monwriter misc device is created with root-only permissions, so practical impact is typically low. Fix this by checking for changed data length and rejecting such records.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72036", "url": "https://ubuntu.com/security/CVE-2026-72036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked multiq_dequeue() takes a packet from a band's child with a direct ->dequeue() call after multiq_peek() peeked it. When the child is non-work-conserving the peek stashes the skb in the child's gso_skb, so the direct dequeue returns a different skb and orphans the stash, desyncing the child's qlen/backlog. With a qfq child reached through a peeking parent (e.g. tbf) this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_prio already does and as sch_red and sch_sfb were just fixed to do. The helper is a no-op when the child has no stash, so a work-conserving child is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72038", "url": "https://ubuntu.com/security/CVE-2026-72038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: fix BAR resource leak on PF number failure If cn23xx_get_pf_num() fails, the function returns without unmapping either BAR. Unmap both BARs before returning from the error path. Found by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72039", "url": "https://ubuntu.com/security/CVE-2026-72039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72229", "url": "https://ubuntu.com/security/CVE-2026-72229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: clean untagged VLAN on netdev registration failure When an mesh interface is registered, it creates an untagged struct batadv_meshif_vlan on top of it via the NETDEV_REGISTER notifier. But in this process, another receiver of this notification can veto the registration. The netdev registration will be aborted because of this veto. The register_netdevice() call will try to clean up the net_device using unregister_netdevice_queue() - which only uses the .priv_destructor to free private resources. In this situation, .dellink will not be called. The cleanup of the untagged batadv_meshif_vlan must thefore be done in the destructor to avoid a leak of this object.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72232", "url": "https://ubuntu.com/security/CVE-2026-72232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: ensure minimal ethernet header on TX As documented in commit 8bd67ebb50c0 (\"net: bridge: xmit: make sure we have at least eth header len bytes\"), it is possible by for a local user with eBPF TC hook access to attach a tc filter which truncates the packet and redirects to an batadv interface. But the code assumes that at least ETH_HLEN bytes are available and thus might read outside of the available buffer. The batadv_interface_tx() must therefore always check itself if enough data is available for the ethernet header and don't rely on min_header_len.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72235", "url": "https://ubuntu.com/security/CVE-2026-72235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: retrieve ethhdr after potential skb realloc on RX pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72047", "url": "https://ubuntu.com/security/CVE-2026-72047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72048", "url": "https://ubuntu.com/security/CVE-2026-72048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix cas_ctl leak on spi_async failure ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72049", "url": "https://ubuntu.com/security/CVE-2026-72049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: admin-gate legacy LLSEC dump operations In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM. Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the \"802.15.4 MAC\" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames. Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family. Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry \"can be retrieved by unprivileged users\" annotations).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72052", "url": "https://ubuntu.com/security/CVE-2026-72052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72054", "url": "https://ubuntu.com/security/CVE-2026-72054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72055", "url": "https://ubuntu.com/security/CVE-2026-72055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink vti6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72056", "url": "https://ubuntu.com/security/CVE-2026-72056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ena: clean up XDP TX queues when regular TX setup fails create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72061", "url": "https://ubuntu.com/security/CVE-2026-72061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sit: require CAP_NET_ADMIN in the device netns for changelink ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72066", "url": "https://ubuntu.com/security/CVE-2026-72066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Bound hotplug states sysfs output states_show() adds CPU hotplug state names into a single sysfs buffer using sprintf(). With enough registered states, this can write past the end of the PAGE_SIZE buffer. Use sysfs_emit_at() so output is bounded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72067", "url": "https://ubuntu.com/security/CVE-2026-72067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Preserve per instance callback errors cpuhp_invoke_callback() unwinds earlier callbacks for the same hotplug state when one instance fails. The rollback path currently reuses ret, so a successful rollback can hide the original error and make the failed transition look successful. Keep the rollback result separate from the original error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72074", "url": "https://ubuntu.com/security/CVE-2026-72074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix type confusion in CDC union descriptor parsing The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72076", "url": "https://ubuntu.com/security/CVE-2026-72076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72078", "url": "https://ubuntu.com/security/CVE-2026-72078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - validate control endpoint type The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72079", "url": "https://ubuntu.com/security/CVE-2026-72079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix use-after-free and double-free in disconnect ims_pcu_disconnect() only intended to perform cleanup when the primary (control) interface is unbound. However, it currently relies on the interface class to distinguish between control and data interfaces. A malicious device could present a data interface with the same class as the control interface, leading to premature cleanup and potential use-after-free or double-free. Switch to verifying that the interface being disconnected is indeed the control interface.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72081", "url": "https://ubuntu.com/security/CVE-2026-72081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix I/O leak on unsupported additional CDB efct_dispatch_fcp_cmd() allocates an efct_io before dispatching an unsolicited FCP command. If the command has an unsupported additional CDB, the function returns -EIO before handing the IO to the SCSI layer. Free the allocated IO before returning from this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72082", "url": "https://ubuntu.com/security/CVE-2026-72082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix refcount leak in efct_hw_io_abort() When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object. Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery. Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72086", "url": "https://ubuntu.com/security/CVE-2026-72086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free the command tag on the TMR submit-failure path scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag. Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails. transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req. Use the same helper, which returns just the tag, on this path too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72088", "url": "https://ubuntu.com/security/CVE-2026-72088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72102", "url": "https://ubuntu.com/security/CVE-2026-72102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm_early_create: fix freeing used table on dm_resume failure If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72105", "url": "https://ubuntu.com/security/CVE-2026-72105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-log: fix a bitset_size overflow on 32bit machines Commit c20e36b7631d (\"dm log: fix out-of-bounds write due to region_count overflow\") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72107", "url": "https://ubuntu.com/security/CVE-2026-72107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix out-of-bounds memory access for non-zero start sector dm-era tracks writes in target-relative blocks, but era_map() calculates the writeset block before applying the target offset. Tables with a non-zero start sector can therefore pass an absolute mapped-device block to metadata_current_marked(). If the absolute block is beyond the current writeset size, writeset_marked() tests past the end of the in-core bitset. KASAN reports this as a vmalloc-out-of-bounds access. Apply the target offset before calculating the era block so writeset lookups use the target-relative block number.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72108", "url": "https://ubuntu.com/security/CVE-2026-72108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm thin metadata: fix metadata snapshot consistency on commit failure __reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata. Reproducer 1: __reserve_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 112 linear /dev/sdc 0 112 3984 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency. dmsetup message tpool 0 \"reserve_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0. Reproducer 2: __release_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 128 linear /dev/sdc 0 128 3968 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata. dmsetup message tpool 0 \"reserve_metadata_snap\" dmsetup message tpool 0 \"release_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked. Fix by deferring the held_root update to commit time. Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72109", "url": "https://ubuntu.com/security/CVE-2026-72109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sparx5: unregister blocking notifier on init failure sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72120", "url": "https://ubuntu.com/security/CVE-2026-72120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu list annotations and operations sashiko-bot remarked the missing use of list_add_rcu() in bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure when bcm_proc_show() traverses the bcm_op's under rcu_read_lock(). To cover all initial settings of the bcm_op's the list_add_rcu() calls are moved to the end of the setup code. While at it, also fix the mirroring removal side: bcm_release() called bcm_remove_op() - which frees the op via call_rcu() - on ops that were still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first. Unlink each op with list_del_rcu() before handing it to bcm_remove_op(), matching the existing pattern in bcm_delete_tx_op()/bcm_delete_rx_op().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72122", "url": "https://ubuntu.com/security/CVE-2026-72122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all mutate both fields under that same lock. Because the lockless reads and the locked writes are unordered with respect to each other, a racing bcm_notify() (device unregister) or bcm_connect() (concurrent bind on another thread sharing the socket) can make bcm_sendmsg() observe an inconsistent combination, e.g. a stale bound=1 together with the now-cleared ifindex=0, silently turning a socket bound to a specific CAN interface into one that also matches \"any\" interface. Keep the lockless bo->bound check purely as a fast-path reject, and move the ifindex read (and a bo->bound re-check) into the locked section, where every writer already serializes. This removes the possibility of observing the two fields torn against each other, rather than trying to fix it with more READ_ONCE()/WRITE_ONCE() pairs on two independently updated fields. Annotate the now-purely-lockless bo->bound accesses consistently across all its write sites. Also fix bcm_rx_setup() silently returning success when the target device disappears concurrently instead of reporting -ENODEV, so a broken RX op is no longer left registered as if it had succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72126", "url": "https://ubuntu.com/security/CVE-2026-72126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72133", "url": "https://ubuntu.com/security/CVE-2026-72133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: Fix completion initialization order before devm_request_irq() The driver calls devm_request_irq() before initializing the completion used by the interrupt handler. Because the interrupt may occur immediately after devm_request_irq(), the handler may execute before init_completion(). This may result in calling complete() on an uninitialized completion, causing undefined behavior. This has been observed with KASAN. Fix this by initializing the completion before registering the IRQ.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72135", "url": "https://ubuntu.com/security/CVE-2026-72135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Make the TPM character devices non-seekable The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset(). Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale. Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged. Tested on Linux 6.12 with KASAN and a swtpm TPM2 device: - sequential partial reads returned the complete response - pread() and preadv() with offset 0x1400 returned -ESPIPE - pwrite() and pwritev() with offset zero returned -ESPIPE - the pending response remained intact after the rejected operations - a subsequent normal command/response cycle completed normally - no KASAN report was produced.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72136", "url": "https://ubuntu.com/security/CVE-2026-72136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72138", "url": "https://ubuntu.com/security/CVE-2026-72138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Fix these issues by properly handling all error cases.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72140", "url": "https://ubuntu.com/security/CVE-2026-72140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource() If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72153", "url": "https://ubuntu.com/security/CVE-2026-72153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72159", "url": "https://ubuntu.com/security/CVE-2026-72159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72160", "url": "https://ubuntu.com/security/CVE-2026-72160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series \"ocfs2: harden inode validators against forged metadata\", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72163", "url": "https://ubuntu.com/security/CVE-2026-72163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72164", "url": "https://ubuntu.com/security/CVE-2026-72164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: avoid moving extents to occupied clusters For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group. The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated. When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run. Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72165", "url": "https://ubuntu.com/security/CVE-2026-72165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: fix condition in 'nand_select_target()' 'cs' here must be in range [0:nanddev_ntargets[.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72166", "url": "https://ubuntu.com/security/CVE-2026-72166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: \terr = io_wait_event_killable(req->wq, ...) \t/* SIGKILL wakes the task, returns -ERESTARTSYS */ \tif (err == -ERESTARTSYS && c->status == Connected && \t\ttype == P9_TFLUSH) { \t\tsigpending = 1; \t\tclear_thread_flag(TIF_SIGPENDING); \t\tgoto again; \t} clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72167", "url": "https://ubuntu.com/security/CVE-2026-72167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72171", "url": "https://ubuntu.com/security/CVE-2026-72171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: slram: remove failed entries from the device list register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72181", "url": "https://ubuntu.com/security/CVE-2026-72181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mips: sched: Fix CPUMASK_OFFSTACK memory corruption This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72182", "url": "https://ubuntu.com/security/CVE-2026-72182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: fix refcount leak in is_full_charged() In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72193", "url": "https://ubuntu.com/security/CVE-2026-72193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: cap RESTART_TABLE free-chain walker at rt->used A crafted NTFS3 disk image triggers an in-kernel infinite loop at mount time, hanging the mounting thread and firing the soft-lockup watchdog within ~22s on multi-CPU hosts (panic with kernel.softlockup_panic=1). The bug is reachable from desktop USB auto-mount on distributions where udisks2 routes the NTFS signature to the in-tree ntfs3 driver (Arch family and an increasing fraction of Fedora / openSUSE / RHEL deployments); CAP_SYS_ADMIN-class manual mount elsewhere. check_rstbl()'s second walker iterates the free-entry singly-linked list headed by rt->first_free with no upper bound on iteration count: for (off = ff; off;) { if (off == RESTART_ENTRY_ALLOCATED) return false; off = le32_to_cpu(*(__le32 *)Add2Ptr(rt, off)); if (off > ts - sizeof(__le32)) return false; } The existing guards cover three exits: end-of-list (off == 0), the in-use marker (off == RESTART_ENTRY_ALLOCATED), and out-of-bounds (off > ts - sizeof(__le32)). None of the three prevents an in-bounds cycle. A crafted on-disk RESTART_TABLE whose free chain contains a self-loop or A->B->A cycle whose offsets satisfy: - in range [sizeof(struct RESTART_TABLE), ts - sizeof(__le32)] - (off - sizeof(struct RESTART_TABLE)) % rsize == 0 passes all existing guards and spins the mount-time thread forever. Reproduced in UML by hand-forging a 2 MB NTFS3 image whose journal RESTART_TABLE first_free = 0x18 and whose entry at offset 0x18 stores 0x18 as its next pointer; mount of the forged image with the in-tree ntfs3 driver never returns. Bound the walker by rt->used. Each entry on a legitimate free chain is unique, and the total slot count is ne = le16_to_cpu (rt->used). A traversal that visits more than ne slots is by construction malformed; reject it as a corrupt RESTART_TABLE. After this patch, mount of the forged image returns with -EINVAL and a log_replay failure message, and mkntfs-produced legitimate images mount cleanly (verified in the same UML harness).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64532", "url": "https://ubuntu.com/security/CVE-2026-64532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation} In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is `Add2Ptr(e, le16_to_cpu(e->view.data_off))`, where e->view.data_off comes from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validates view.data_off + dlen against e->size; the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate the entry's offset, but not its internal view fields. The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <= e->size. Apply the same bound at the two memmove sites. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE. This is similar in shape to Pavitra Jha's 2026-05-02 patch \"fs/ntfs3: prevent oob in case UpdateRecordDataRoot\" (<20260502105008.21827-1-jhapavitra98@gmail.com>) which proposes calling ntfs3_bad_de_range(); that helper does not exist in mainline. This patch uses inline checks.", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64533", "url": "https://ubuntu.com/security/CVE-2026-64533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate lcns_follow in log_replay conversion log_replay() converts DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY records when replaying version 0 restart tables. During this conversion, the memmove() length is derived directly from the on-disk lcns_follow field: \tmemmove(&dp->vcn, &dp0->vcn_low, \t\t2 * sizeof(u64) + \t\t\t\tle32_to_cpu(dp->lcns_follow) * sizeof(u64)); check_rstbl() validates restart table structure, but does not constrain per-entry lcns_follow values relative to the entry size. A malformed filesystem image can provide an oversized lcns_follow value, causing the conversion memmove() to access memory beyond the bounds of the allocated restart table buffer. The same field is later used to bound iteration over page_lcns[], so validating lcns_follow during conversion also prevents downstream out-of-bounds access from the same malformed metadata. Compute the maximum valid lcns_follow from the already-validated restart table entry size and reject entries that exceed this bound. Reuse the existing t16/t32 scratch variables already declared in log_replay() to avoid introducing new declarations. [almaz.alexandrovich@paragon-software.com: fixed the conflicts]", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72195", "url": "https://ubuntu.com/security/CVE-2026-72195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment \tattr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72197", "url": "https://ubuntu.com/security/CVE-2026-72197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: \tif (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || \t Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || \t used + esize > le32_to_cpu(hdr->total)) { \t\tgoto dirty_vol; \t} Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72215", "url": "https://ubuntu.com/security/CVE-2026-72215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002. To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant. Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and \"if it ain't broke, don't fix it,\" so just leave them alone.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72218", "url": "https://ubuntu.com/security/CVE-2026-72218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72219", "url": "https://ubuntu.com/security/CVE-2026-72219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file leak when nlm_do_fopen() fails A client can repeatedly drive nlm_do_fopen() failures by presenting file handles that the underlying export rejects. After kzalloc_obj() succeeds in nlm_lookup_file(), the freshly allocated nlm_file is not yet inserted into nlm_files[]. The nlm_do_fopen() failure path jumps to out_unlock, which releases nlm_file_mutex and returns without freeing the allocation, so each failure leaks one nlm_file. Route the failure through out_free so kfree() runs before the function returns.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72223", "url": "https://ubuntu.com/security/CVE-2026-72223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arena sub-allocations on discover_arenas() error path Memory allocated by btt_freelist_init(), btt_rtt_init(), and btt_maplocks_init() is not freed on some discover_arenas() error paths. This leaks memory when arena discovery fails. Add the missing kfree() calls to release the allocations before returning an error. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72224", "url": "https://ubuntu.com/security/CVE-2026-72224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arenas on btt_init() error paths The arenas allocated by discover_arenas() or create_arenas() are not freed on some error paths in btt_init(). This leaks memory when BTT initialization fails. Call free_arenas() from the affected error paths to release the allocations. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72225", "url": "https://ubuntu.com/security/CVE-2026-72225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit() jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check. The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort. Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72228", "url": "https://ubuntu.com/security/CVE-2026-72228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: fix primary_if leak on failed linearization If the skb has a frag_list, it must be linearized before it can be split using skb_split(). But when this step failed, it must not only free the skb but also take care of the reference to the already found primary_if.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72230", "url": "https://ubuntu.com/security/CVE-2026-72230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72231", "url": "https://ubuntu.com/security/CVE-2026-72231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is \"ret == false\". But the actual implementation is checking for \"ret == true\". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72233", "url": "https://ubuntu.com/security/CVE-2026-72233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: reacquire gw address after skb realloc The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72238", "url": "https://ubuntu.com/security/CVE-2026-72238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/boot: Validate console=uart8250 baud rate to fix early boot hang When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72240", "url": "https://ubuntu.com/security/CVE-2026-72240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72241", "url": "https://ubuntu.com/security/CVE-2026-72241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: uleds: Fix potential buffer overread The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72245", "url": "https://ubuntu.com/security/CVE-2026-72245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64554", "url": "https://ubuntu.com/security/CVE-2026-64554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() br_ip6_fragment() gets prevhdr, a pointer into the skb head, from ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb skb_checksum_help() reallocates the head via pskb_expand_head(), leaving prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a use-after-free write. Save prevhdr's offset before skb_checksum_help() and recompute it after, like commit ef0efcd3bd3f (\"ipv6: Fix dangling pointer when ipv6 fragment\"). BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857) Write of size 1 at addr ffff888013ff5016 by task exploit/141 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip6_frag_next (net/ipv6/ip6_output.c:857) br_ip6_fragment (net/ipv6/netfilter.c:212) nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407) nf_hook_slow (net/netfilter/core.c:619) br_forward_finish (net/bridge/br_forward.c:66) __br_forward (net/bridge/br_forward.c:115) maybe_deliver (net/bridge/br_forward.c:191) br_flood (net/bridge/br_forward.c:245) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:442) ... packet_sendmsg (net/packet/af_packet.c:3114) ... do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72247", "url": "https://ubuntu.com/security/CVE-2026-72247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: fix zone comparison in tuple dedup The \"already exists\" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument. Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone. nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents. Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72250", "url": "https://ubuntu.com/security/CVE-2026-72250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header: \tskb->mac_header += sizeof(struct frag_hdr); On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the \"not set\" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom. The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72256", "url": "https://ubuntu.com/security/CVE-2026-72256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_cluster: reject template conntracks in hash match xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72264", "url": "https://ubuntu.com/security/CVE-2026-72264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tridentfb: fix potential memory leak in trident_pci_probe() In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72265", "url": "https://ubuntu.com/security/CVE-2026-72265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: nvidia: fix potential memory leak in nvidiafb_probe() In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72267", "url": "https://ubuntu.com/security/CVE-2026-72267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: carminefb: fix potential memory leak in alloc_carmine_fb() The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72268", "url": "https://ubuntu.com/security/CVE-2026-72268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe() In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72269", "url": "https://ubuntu.com/security/CVE-2026-72269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: fix potential memory leak in uvesafb_probe() Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. Fix this by updating the goto label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72270", "url": "https://ubuntu.com/security/CVE-2026-72270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: s3fb: fix potential memory leak in s3_pci_probe() In s3_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72271", "url": "https://ubuntu.com/security/CVE-2026-72271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: i740fb: fix potential memory leak in i740fb_probe() In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72272", "url": "https://ubuntu.com/security/CVE-2026-72272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: radeon: fix potential memory leak in radeonfb_pci_register() The function radeonfb_pci_register() allocates memory for modelist (by calling radeon_check_modes() which calls fb_add_videomode()). The memory is appended to info->modelist, but is not freed in subsequent error paths. Fix this by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72274", "url": "https://ubuntu.com/security/CVE-2026-72274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: hecubafb: fix potential memory leak in hecubafb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72275", "url": "https://ubuntu.com/security/CVE-2026-72275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72276", "url": "https://ubuntu.com/security/CVE-2026-72276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: metronomefb: fix potential memory leak in metronomefb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72297", "url": "https://ubuntu.com/security/CVE-2026-72297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72298", "url": "https://ubuntu.com/security/CVE-2026-72298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with \tif (!size || len != ALIGN(size, 4) + hdrlen) \t\tgoto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 (\"net: qrtr: fix OOB Read in qrtr_endpoint_post\"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72306", "url": "https://ubuntu.com/security/CVE-2026-72306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72307", "url": "https://ubuntu.com/security/CVE-2026-72307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree. Fix by reinitializing vr inside the error loop with the updated index: \tvr = &mlxsw_sp->router->vrs[i]; so that the loop correctly iterates over all VRs that were actually replaced.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72310", "url": "https://ubuntu.com/security/CVE-2026-72310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds.", "cve_priority": "negligible", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72314", "url": "https://ubuntu.com/security/CVE-2026-72314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72316", "url": "https://ubuntu.com/security/CVE-2026-72316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix NULL pointer dereference in metadata_open() metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72326", "url": "https://ubuntu.com/security/CVE-2026-72326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cake: reject overhead values that underflow length CAKE accepts signed overhead values and stores them in an s16, but the adjusted packet length calculation uses unsigned arithmetic. A negative effective length can therefore wrap to a large value. Such configurations make rate accounting depend on integer wraparound rather than on the packet size userspace intended to model. A static netlink lower bound is not enough because packets reaching CAKE can be smaller than any reasonable manual-overhead allowance. Fold the signed overhead adjustment into the existing datapath MPU clamp so negative adjusted lengths are clamped before link-layer framing adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64549", "url": "https://ubuntu.com/security/CVE-2026-64549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup() bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length: \tbt_dev_info(hdev, \"%s\", (char *)(skb->data + 1)); \thci_set_fw_info(hdev, \"%s\", skb->data + 1); A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file. Print the revision string with a bounded \"%.*s\" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64550", "url": "https://ubuntu.com/security/CVE-2026-64550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: validate MAP frame length before ingress parsing When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes the skb straight to __rmnet_map_ingress_handler(), skipping the length validation that rmnet_map_deaggregate() performs on the aggregated path. The parser then dereferences the MAP header and csum header/trailer based on the on-wire pkt_len without checking skb->len, so a short frame is read out of bounds: BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet Read of size 1 at addr ffff88801118ed00 by task exploit/147 Call Trace: ... rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413) __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089) netif_receive_skb (net/core/dev.c:6460) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2001) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Factor that validation out of rmnet_map_deaggregate() into rmnet_map_validate_packet_len() and run it on the no-aggregation path too. The MAP header is bounds-checked first, since this path can receive a frame shorter than the header.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72347", "url": "https://ubuntu.com/security/CVE-2026-72347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_connmark: reject invalid shift parameters Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmark_tg_shift(). A shift_bits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shift_dir values are also accepted and silently fall back to the left-shift path. Reject invalid revision-2 shift parameters in connmark_tg_check() so malformed rules fail at installation time, before they can reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72349", "url": "https://ubuntu.com/security/CVE-2026-72349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt() On links faster than ~34 Gbps, where byte rate may exceed 2^32-1 (~ 4.3 GBps), the comparison result becomes incorrect because the truncated value no longer reflects the actual estimator rate. Fix by changing the local variables to u64.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72350", "url": "https://ubuntu.com/security/CVE-2026-72350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_u32: reject invalid shift counts u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation. Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64547", "url": "https://ubuntu.com/security/CVE-2026-64547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: net1080: validate packet_len before pad-byte access in rx_fixup For an even packet_len, net1080_rx_fixup() reads the pad byte at skb->data[packet_len] before the skb->len != packet_len check further down, and packet_len is only bounded against NC_MAX_PACKET. A malicious NetChip 1080 device can send a short frame advertising a large even packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the skb: BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14 ... net1080_rx_fixup (drivers/net/usb/net1080.c:384) usbnet_bh (drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3708) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) ... Reject the frame when packet_len >= skb->len before reading.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72371", "url": "https://ubuntu.com/security/CVE-2026-72371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the volume AFS_VOLUME_RM_TREE is set on Fix afs_insert_volume_into_cell() to set AFS_VOLUME_RM_TREE on the volume replaced, not the new volume, as it's now removed from the cell's volume tree. This will cause the old volume to be removed from the tree twice and the new volume never to be removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72374", "url": "https://ubuntu.com/security/CVE-2026-72374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix callback service message parsers to pass through -EAGAIN The AFS filesystem client uses an rxrpc server to listen for callback notifications. Each callback call type handler has a delivery function that parses the incoming request stream, and this should return -EAGAIN the last packet hasn't yet been seen, but all currently queued received data is consumed. afs_extract_data() does this, but the -EAGAIN return is switched to 0 inadvertantly Fix callback service message parsers to pass through -EAGAIN", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72378", "url": "https://ubuntu.com/security/CVE-2026-72378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix error code in afs_extract_vl_addrs() The error codes on these paths are only set on the first iteration through the loop. Set the correct error code on every iteration.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72389", "url": "https://ubuntu.com/security/CVE-2026-72389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: stp: Fix a potential use-after-free when deleting a bridge The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them. This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted. Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted. [1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64540", "url": "https://ubuntu.com/security/CVE-2026-64540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup() genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received. A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes. \tskb_put_data(gl_skb, packet->packet_data, size); then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up. BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72392", "url": "https://ubuntu.com/security/CVE-2026-72392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72396", "url": "https://ubuntu.com/security/CVE-2026-72396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: adm1275: Prevent reading uninitialized stack While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret < 0) { ... } for (mid = adm1275_id; mid->name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like \"adm12\", checking it against \"adm1275\" up to the length of \"adm1275\" will continue reading into uninitialized stack bounds. Prevent reading uninitialized memory by zeroing the stack array.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72400", "url": "https://ubuntu.com/security/CVE-2026-72400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: validate SRH length before reading fixed fields seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields. The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer. Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72406", "url": "https://ubuntu.com/security/CVE-2026-72406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sungem: fix probe error cleanup gem_init_one() calls gem_remove_one() when register_netdev() fails. gem_remove_one() unregisters and frees resources owned by the net_device, including the DMA block, MMIO mapping, PCI regions, and the net_device itself. gem_init_one() then falls through to its own cleanup labels and frees the same resources again. Keep the register_netdev() error path in gem_init_one(): clear drvdata so PM/remove paths do not see a half-registered device, remove the NAPI instance added during probe, and let the existing cleanup labels release the resources once. The issue was found by a local static-analysis checker for probe error paths. The reported path was manually inspected before sending this fix. Compile-tested with CONFIG_SUNGEM=y. Runtime testing was not performed because no sungem hardware is available.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72409", "url": "https://ubuntu.com/security/CVE-2026-72409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvneta: re-enable percpu interrupt on resume On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules NAPI poll, which calls enable_percpu_irq() on completion to unmask. If suspend occurs while NAPI poll is pending (between disable_percpu_irq in the ISR and enable_percpu_irq in poll completion), the interrupt is never re-enabled: 1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule() => MPIC masked, percpu_enabled cpumask bit cleared 2. NAPI poll does not complete before suspend proceeds (on PREEMPT_RT this is highly likely since softirqs run in ksoftirqd which gets frozen; on non-RT it can happen when softirq processing is deferred to ksoftirqd) 3. mvneta_stop_dev => napi_disable(): cancels the pending poll without executing the completion path 4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC (already masked, but records IRQS_SUSPENDED) 5. Resume: mpic_resume checks irq_percpu_is_enabled() => false (bit was cleared in step 1) => skips unmask 6. mvneta_start_dev only restores device-level INTR_NEW_MASK, does not touch the MPIC per-CPU mask Result: MPIC per-CPU interrupt stays masked permanently. The NIC generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never receives them, causing complete loss of network connectivity. Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path to unconditionally unmask the MPIC per-CPU interrupt regardless of pre-suspend state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72414", "url": "https://ubuntu.com/security/CVE-2026-72414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: round up PTP perout pin duration pin_duration is converted from the user-provided period to SJA1105 clock ticks and is later passed as the cycle_time argument to future_base_time(). Very small period values may become zero after the conversion, which can lead to a division by zero in future_base_time(). Round zero pin_duration up to 1 tick so that the smallest unsupported periods use the minimum non-zero hardware duration instead of passing zero to future_base_time().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64545", "url": "https://ubuntu.com/security/CVE-2026-64545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net, bpf: check master for NULL in xdp_master_redirect() xdp_master_redirect() dereferences the result of netdev_master_upper_dev_get_rcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency. The reach guard only checks netif_is_bond_slave(). On bond slave release bond_upper_dev_unlink() drops the upper-master adjacency before clearing IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window still passes netif_is_bond_slave() while master is already NULL, and faults on master->flags at offset 0xb0: BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdp_master_redirect (net/core/filter.c:4432) Call Trace: xdp_master_redirect (net/core/filter.c:4432) bpf_prog_run_generic_xdp (include/net/xdp.h:700) do_xdp_generic (net/core/dev.c:5608) __netif_receive_skb_one_core (net/core/dev.c:6204) process_backlog (net/core/dev.c:6319) __napi_poll (net/core/dev.c:7729) net_rx_action (net/core/dev.c:7792) handle_softirqs (kernel/softirq.c:622) __dev_queue_xmit (include/linux/bottom_half.h:33) packet_sendmsg (net/packet/af_packet.c:3082) __sys_sendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt The missing check dates back to the original code; commit 1921f91298d1 (\"net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master\") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72418", "url": "https://ubuntu.com/security/CVE-2026-72418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: prevent connlimit drops for early confirmed ct Commit 69894e5b4c5e (\"netfilter: nft_connlimit: update the count if add was skipped\") introduced a regression where packets for valid connections are dropped when using connlimit for soft-limiting scenarios. The issue occurs when a new connection reuses a socket currently in the TIME_WAIT state. In this scenario, the connection tracking entry is evaluated as already confirmed. Previously, __nf_conncount_add() assumed that if a connection was confirmed and did not originate from the loopback interface, it should skip the addition and return -EEXIST. Skipping the addition triggers a garbage collection run that cleans up the TIME_WAIT connection. Consequently, the active connection count drops to 0, which xt_connlimit mishandles, leading to the false rejection of the perfectly valid new connection. Fix this by replacing the interface check with protocol-agnostic state checks. We now skip the tree insertion and preserve the lockless garbage collection optimization only if the connection is IPS_ASSURED. This allows early-confirmed setup packets (such as reused TIME_WAIT sockets or locally generated SYN-ACKs) to be properly evaluated and counted without falsely dropping. The goto check_connections path is maintained to ensure these setup packets are deduplicated correctly. This has been tested with slowhttptest and HTTP server configured locally to ensure we are not breaking soft-limiting scenarios for local or external connections. In addition, it was tested with a OVS zone limit too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72421", "url": "https://ubuntu.com/security/CVE-2026-72421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't ignore error route in local/main tables. When CONFIG_IP_MULTIPLE_TABLES is enabled but no rule is added, fib_lookup() performs route lookup directly on two tables. Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table: # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache Once a random rule is added, the error route is respected: # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host Let's fix the inconsistent behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64538", "url": "https://ubuntu.com/security/CVE-2026-64538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix null-ptr-deref in fib6_nh_mtu_change(). fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown() clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(), but this re-fetch is unguarded; nexthop-backed routes survive addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is nulled. Return 0 when idev is NULL, matching rt6_mtu_change_route() and the fib6_mtu() fix in commit 5ad509c1fdad (\"ipv6: Fix null-ptr-deref in fib6_mtu().\"). Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6_nh_mtu_change+0x203/0x990 rt6_mtu_change_route+0x141/0x1d0 __fib6_clean_all+0xd0/0x160 rt6_mtu_change+0xb4/0x100 ndisc_router_discovery+0x24b5/0x2cb0 icmpv6_rcv+0x12e9/0x1710 ipv6_rcv+0x39b/0x410", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64546", "url": "https://ubuntu.com/security/CVE-2026-64546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72428", "url": "https://ubuntu.com/security/CVE-2026-72428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack slot index in nospec checks check_stack_write_fixed_off() computes the byte slot for a fixed-offset stack write as -off - 1, and records each written byte in slot_type[] with (slot - i) % BPF_REG_SIZE. The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a 4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates bytes 7..4. That can leave the second half-slot write without nospec_result even though the bytes being overwritten still require sanitization. Use the same slot index in the sanitization pre-check that the write path uses when updating slot_type[].", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72433", "url": "https://ubuntu.com/security/CVE-2026-72433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak This needs to test for nonzero retval.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72435", "url": "https://ubuntu.com/security/CVE-2026-72435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer() Sashiko pointed out that kfree_rcu() was called before rcu_assign_pointer() in handling the comment extension. Fix the order so that rcu_assign_pointer() called first.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72441", "url": "https://ubuntu.com/security/CVE-2026-72441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: fix kernel-infoleak in dgram_recvmsg() KMSAN reported a kernel-infoleak in move_addr_to_user(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925 ... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739 The issue occurs because the `pan_id` field of `struct ieee802154_addr` is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`. The execution flow is as follows: 1. `__ieee802154_rx_handle_packet()` declares a local `struct ieee802154_hdr hdr` on the stack. 2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse the source and destination addresses into this structure. 3. If the address mode is `IEEE802154_ADDR_NONE`, `ieee802154_hdr_get_addr()` previously only set the `mode` field, leaving the `pan_id` field containing uninitialized stack memory. 4. This uninitialized `pan_id` is later copied into a `struct sockaddr_ieee802154` in `dgram_recvmsg()` via `ieee802154_addr_to_sa()`. 5. Finally, `move_addr_to_user()` copies the socket address structure to user space, leaking the uninitialized bytes. Fix this by using `memset` to zero out the address structure in `ieee802154_hdr_get_addr()` when the mode is `IEEE802154_ADDR_NONE`.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72447", "url": "https://ubuntu.com/security/CVE-2026-72447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: hold socket lock when dumping endpoints in sctp_diag SCTP_DIAG endpoint dumping was traversing endpoint address lists without holding lock_sock(), while those lists could change concurrently via socket operations (e.g., bindx changes). This creates a race where nla_reserve() counts addresses under RCU protection, but the subsequent copy may see fewer entries, potentially leaking uninitialized memory to userspace. Fix this by: - Taking a reference on each endpoint during hash traversal - Moving socket operations (lock_sock()) outside read_lock_bh() - Serializing address list access during dump - Reworking sctp_for_each_endpoint() to support restart-based traversal with (net, pos) tracking Also: - Add WARN_ON_ONCE() for inconsistent address counts - Fix idiag_states filtering for LISTEN vs association cases - Skip dumping endpoints being freed (ep->base.dead) - Move dump position tracking into iterator, removing cb->args[4] and its comment for sctp_ep_dump()., - Update the comment for cb->args[4] and remove the comment for unused cb->args[5] for sctp_sock_dump(). Note: traversal is restart-based and may re-scan buckets multiple times, but this is acceptable due to small bucket sizes and required to support sleeping-safe callbacks. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64553", "url": "https://ubuntu.com/security/CVE-2026-64553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: psample: fix info leak in PSAMPLE_ATTR_DATA psample open codes nla_put() presumably to avoid wiping the data with 0s just to override it with packet data. This open coding is missing clearing the pad, however, each netlink attr is padded to 4B and data_len may not be divisible by 4B.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72448", "url": "https://ubuntu.com/security/CVE-2026-72448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix leak of SQ timestamp buffer on teardown The send-queue timestamp ring is allocated with qmem_alloc() when timestamping is used, but otx2_free_sq_res() never freed sq->timestamps, leaking that memory across ifdown and device removal. Add the missing qmem_free() alongside the other SQ companion buffers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72450", "url": "https://ubuntu.com/security/CVE-2026-72450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate selector family and prefixlen during match syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72459", "url": "https://ubuntu.com/security/CVE-2026-72459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: aa_label_alloc use aa_label_free on alloc failure aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init(). Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72460", "url": "https://ubuntu.com/security/CVE-2026-72460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72476", "url": "https://ubuntu.com/security/CVE-2026-72476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix possible use after free In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72479", "url": "https://ubuntu.com/security/CVE-2026-72479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: mma8452: handle I2C read error(s) in mma8452_read() Currently, If i2c_smbus_read_i2c_block_data() fails but mma8452_set_runtime_pm_state() succeeds, mma8452_read() returns 0. As a result, the caller mma8452_read_raw() assumes the read was successful and proceeds to use a buffer containing uninitialized stack memory. Add proper checking of the I2C read return value and propagate errors to the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72481", "url": "https://ubuntu.com/security/CVE-2026-72481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: ak8975: fix potential kernel stack memory leak Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72483", "url": "https://ubuntu.com/security/CVE-2026-72483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72484", "url": "https://ubuntu.com/security/CVE-2026-72484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: video: avoid double free on video register failure comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72489", "url": "https://ubuntu.com/security/CVE-2026-72489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: nvec: fix use-after-free in nvec_rx_completed() In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72492", "url": "https://ubuntu.com/security/CVE-2026-72492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in same_client_has_lease() same_client_has_lease() returns an opinfo pointer from ci->m_op_list after dropping ci->m_lock without taking a reference. smb_grant_oplock() then dereferences that pointer in copy_lease() and when checking breaking_cnt. A concurrent close can remove the old lease from ci->m_op_list and drop the last reference before the caller uses the returned pointer, leading to a use-after-free. Take a reference when same_client_has_lease() selects an existing lease, drop any previous match while scanning, and release the returned reference in smb_grant_oplock() after copying the lease state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72502", "url": "https://ubuntu.com/security/CVE-2026-72502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF) When MTU is large, ip6_default_advmss() can return IPV6_MAXPLEN (65535). This is interpreted by TCP as mss_clamp, allowing the MSS to reach 65535. However, 0xFFFF is also used as a magic value GSO_BY_FRAGS in the kernel. If a TCP packet with gso_size=0xFFFF is passed to skb_segment(), it will be mistakenly treated as GSO_BY_FRAGS, leading to a NULL pointer dereference because local TCP packets do not use frag_list. Fix this by returning min(IPV6_MAXPLEN, GSO_BY_FRAGS - 1) (65534) from ip6_default_advmss() when MTU is large. Also update the stale comment in ip6_default_advmss() which suggested that IPV6_MAXPLEN is returned to mean \"any MSS\".", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74256", "url": "https://ubuntu.com/security/CVE-2026-74256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check start and len are u32, so \tu64 last = start + len; evaluates start + len in 32-bit and wraps before storing it in last. The bounds check \tif (start >= offset + l || last > msg->sg.size) \t\treturn -EINVAL; can then be passed with an out-of-range start/len, after which the pop loop runs off the end of the scatterlist and sk_msg_shift_left() calls put_page() on the empty msg->sg.end slot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:sk_msg_shift_left net/core/filter.c:2957 [inline] RIP: 0010:____bpf_msg_pop_data net/core/filter.c:3103 [inline] RIP: 0010:bpf_msg_pop_data+0x753/0x1a10 net/core/filter.c:2984 Call Trace: bpf_prog_4cc92c278f4d5d56+0x1b1/0x1e8 bpf_prog_run_pin_on_cpu+0x107/0x320 include/linux/filter.h:746 sk_psock_msg_verdict+0x357/0x7f0 net/core/skmsg.c:934 tcp_bpf_send_verdict net/ipv4/tcp_bpf.c:420 [inline] tcp_bpf_sendmsg+0x766/0x1ae0 net/ipv4/tcp_bpf.c:583 __sock_sendmsg+0x153/0x1c0 net/socket.c:802 __sys_sendto+0x326/0x430 net/socket.c:2265 __x64_sys_sendto+0xe3/0x100 net/socket.c:2268 do_syscall_64+0x14c/0x480 entry_SYSCALL_64_after_hwframe+0x77/0x7f Widen the addition with a (u64) cast so the bound is evaluated in 64-bit and a len near U32_MAX no longer wraps below msg->sg.size. While here, change pop from int to u32. It counts bytes against the unsigned scatterlist lengths and can never be negative, so the signed type only invites sign-confusion in the pop loop.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64548", "url": "https://ubuntu.com/security/CVE-2026-64548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data() When the scatterlist ring is full or nearly full, bpf_msg_push_data() enters a copy fallback path and computes copy + len for the page allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING and both are u32, a crafted len can wrap the sum to a small value, causing an undersized allocation followed by an out-of-bounds memcpy. BUG: unable to handle page fault for address: ffffed104089a402 Oops: Oops: 0000 [#1] SMP KASAN NOPTI Call Trace: __asan_memcpy (mm/kasan/shadow.c:105) bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) bpf_prog_9ed8b5711920a7d7+0x2e/0x36 sk_psock_msg_verdict (net/core/skmsg.c:934) tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) __sys_sendto (net/socket.c:2206) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add an overflow check before the allocation.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74262", "url": "https://ubuntu.com/security/CVE-2026-74262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcm: use WRITE_ONCE() when changing lower socket callbacks kcm_attach() replaces a live lower TCP socket's sk_data_ready and sk_write_space callbacks with KCM handlers, and kcm_unattach() restores them later. Those callback-pointer updates are still plain stores even though the same fields can be read and invoked concurrently on other CPUs. If another CPU observes an older callback snapshot after the live field has already been restored, callback execution can run with a mismatched target and sk_user_data state, leading to stale or misdirected wakeups. Use WRITE_ONCE() for the callback replacement and restore operations so these shared callback fields follow the same visibility contract already established by the earlier 4022 fixes.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74265", "url": "https://ubuntu.com/security/CVE-2026-74265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: initialize gdma queue id to INVALID_QUEUE_ID mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74276", "url": "https://ubuntu.com/security/CVE-2026-74276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: xilinx: use FIFO occupancy register to determine buffer size The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. When a SPI transaction wants to write the amount of the FIFO size or more bytes, the following happens, for example with 16 bytes FIFO size: The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and starts the SPI hardware and goes sleep. The hardware then shifts out 17 bytes (FIFO + shift register) and simultaneously reads bytes into the RX FIFO, but it only has 16 places, so it looses one byte. Then TX FIFO empty asserts, wakes the driver again, which has a fast path and reads 16 bytes from the RX FIFO, but before reading the last 17th byte (which is lost) it does this: \tsr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); \tif (!(sr & XSPI_SR_RX_EMPTY_MASK)) { \t\txilinx_spi_rx(xspi); \t\trx_words--; \t} It reads the status register and checks if the RX FIFO is not empty. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74279", "url": "https://ubuntu.com/security/CVE-2026-74279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: cavium/cpt - fix DMA cleanup using wrong loop index The sg_cleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74280", "url": "https://ubuntu.com/security/CVE-2026-74280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/octeontx - fix DMA cleanup using wrong loop index The sg_cleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74281", "url": "https://ubuntu.com/security/CVE-2026-74281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74282", "url": "https://ubuntu.com/security/CVE-2026-74282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: prevent snt_unacked underflow on CONN_ACK tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: \ttsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74283", "url": "https://ubuntu.com/security/CVE-2026-74283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74284", "url": "https://ubuntu.com/security/CVE-2026-74284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: Don't make class passive twice update_vf() is called from two places for the same class during a single dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last packets while dequeuing: 1. The child calls qdisc_tree_reduce_backlog(), which, now that the child is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns the class passive (cl_nactive is decremented up the hierarchy). 2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time) to charge the dequeued bytes. On the second call the class is already passive, but its child qdisc is still empty, so update_vf() arms go_passive again: if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1; The leaf is then skipped by the cl_nactive == 0 check inside the loop, which does not clear go_passive, so the stale go_passive propagates to the parent and decrements its cl_nactive a second time. A parent that still has other active children is driven to cl_nactive == 0 and removed from the vttree, even though those siblings are still backlogged. They are never dequeued again and the qdisc stalls. Fix this by only arming go_passive when the class is actually active, so an already-passive class no longer triggers a second passive transition. The byte accounting (cl->cl_total += len) still runs for every ancestor, so dequeued bytes continue to be counted exactly once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64537", "url": "https://ubuntu.com/security/CVE-2026-64537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: reject invalid CCM interval at configuration time ccm_tx_work_expired() re-arms itself via queue_delayed_work() using the configured exp_interval converted by interval_to_us(). When exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range, interval_to_us() returns 0, causing the worker to fire immediately in a tight loop that allocates skbs until OOM. Fix this by validating exp_interval at configuration time: - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the netlink policy so userspace cannot set an invalid value. - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not yet been configured (defaults to 0 from kzalloc).", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74288", "url": "https://ubuntu.com/security/CVE-2026-74288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fib_rules: Don't dump dying fib_rule in fib_rules_dump(). rocker_router_fib_event() calls fib_rule_get() during RCU dump. If the fib_rule is dying, refcount_inc() will complain about it. Let's call refcount_inc_not_zero() in fib_rules_dump().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74292", "url": "https://ubuntu.com/security/CVE-2026-74292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tegra: tegra210_ahub: Validate written enum value tegra_ahub_put_value_enum() reads e->values[item[0]] before checking whether item[0] is within the enum item range. The existing check therefore happens too late to prevent an out-of-range read of the values array. Move the check before the array access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74293", "url": "https://ubuntu.com/security/CVE-2026-74293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: fsl_audmix: Validate written enum values fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src() convert the user-provided enum item with snd_soc_enum_item_to_val() before checking whether the item is within the enum's item count. The generic snd_soc_put_enum_double() helper performs that validation, but these callbacks use the converted value first: the clock-source path tests it with BIT(), and the output-source path indexes the prms transition table with it. Reject out-of-range enum items before converting them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74295", "url": "https://ubuntu.com/security/CVE-2026-74295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: hdac_hdmi: Validate written enum value hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range. An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74297", "url": "https://ubuntu.com/security/CVE-2026-74297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix undefined shift of user RQ WQE size set_rq_size() computes the RQ WQE size as \"1 << rq_wqe_shift\" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74305", "url": "https://ubuntu.com/security/CVE-2026-74305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tighten cgroup storage cookie checks for prog arrays The fix in commit abad3d0bad72 (\"bpf: Fix oob access in cgroup local storage\") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74312", "url": "https://ubuntu.com/security/CVE-2026-74312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: validate virtqueue index in mmap and fault paths vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74313", "url": "https://ubuntu.com/security/CVE-2026-74313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: hold vduse_lock across IDR lookup in open path vduse_dev_open() looks up struct vduse_dev through the IDR and then acquires dev->lock only after vduse_lock has been dropped. This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the same object from the IDR and free it before the open path locks the device, leading to a use-after-free. Close this race by keeping vduse_lock held until dev->lock has been acquired in the open path, matching the lock ordering already used by the destroy path.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74320", "url": "https://ubuntu.com/security/CVE-2026-74320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, \"mode\", &len) is just written over either the static \"640x480-16@60\" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74321", "url": "https://ubuntu.com/security/CVE-2026-74321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 (\"btrfs: refactor __btrfs_run_delayed_refs loop\") but were unintentionally lost afterwards.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74327", "url": "https://ubuntu.com/security/CVE-2026-74327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmalloc: fix NULL pointer dereference in is_vm_area_hugepages() find_vm_area() can return NULL if the given address is not a valid vmalloc area. Check the return value before dereferencing it to avoid a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74329", "url": "https://ubuntu.com/security/CVE-2026-74329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: unregister PM notifier on watchdog unregister watchdog_register_device() registers wdd->pm_nb when WDOG_NO_PING_ON_SUSPEND is set, but watchdog_unregister_device() does not remove it. This leaves an embedded notifier block on the PM notifier chain after the watchdog device has been unregistered. A later suspend/resume notification can then call watchdog_pm_notifier() with a stale watchdog_device pointer, or at minimum after wdd->wd_data has been cleared by watchdog_dev_unregister(). Unregister the PM notifier before tearing down the watchdog device.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74330", "url": "https://ubuntu.com/security/CVE-2026-74330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: fix lockless traversals of ->s_children Having the parent directory locked protects entries from removal by another thread, but it does *not* protect cursors from being moved around by lseek() - or freed, for that matter.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74331", "url": "https://ubuntu.com/security/CVE-2026-74331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix recursive lock in device_cache_fw_images() A recursive locking deadlock can occur in the firmware loader's power management notification handler. During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock. For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread. The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock. Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74339", "url": "https://ubuntu.com/security/CVE-2026-74339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Clear variable event pointer on read snd_seq_read() copies a queued variable-length event header to userspace before expanding the payload. Queued variable-length events use SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first extension cell. The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the copy, but it leaves data.ext.ptr untouched. A userspace sequencer client can therefore write a direct variable event to itself and read back the extension-cell kernel address from the returned header. Clear the temporary header pointer before copy_to_user(). The original queued event remains unchanged and is still passed to snd_seq_expand_var_event(), so payload expansion keeps using the internal chain.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74340", "url": "https://ubuntu.com/security/CVE-2026-74340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74346", "url": "https://ubuntu.com/security/CVE-2026-74346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74348", "url": "https://ubuntu.com/security/CVE-2026-74348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: require a ref for locking_state debugfs open debug_lockres_open() copies inode->i_private into struct debug_lockres and debug_lockres_release() later drops that pointer with dlm_put(). That only works if open successfully pins the struct dlm_ctxt. Today open calls dlm_grab(dlm) but ignores its return value. Once the last domain unregister has removed the context from dlm_domains, dlm_grab() returns NULL, yet open still stores the raw pointer and returns success. The later release path is outside the debugfs removal barrier, so it can call dlm_put() after dlm_free_ctxt_mem() has freed the context. KASAN reports this as a slab-use-after-free in dlm_put() called from debug_lockres_release(). Fail the open when dlm_grab() cannot acquire the reference and unwind the seq_file private state before returning. That keeps locking_state from handing out a file descriptor whose release path does not own the dlm_ctxt. The buggy scenario involves two paths, with each column showing the order within that path: locking_state debugfs open: last domain unregister: 1. debug_lockres_open() reads 1. dlm_unregister_domain() calls inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() calls 2. shutdown removes the dlm_ctxt from dlm_grab(dlm) and gets NULL. dlm_domains. 3. open still stores the raw dlm 3. final teardown reaches pointer in dl->dl_ctxt and dlm_free_ctxt_mem() and frees it. returns success. 4. debug_lockres_release() later calls dlm_put(dl->dl_ctxt). Validation reproduced this kernel report: KASAN slab-use-after-free in dlm_put+0x82/0x200 RIP: 0033:0x7f4d349bc9e0 The buggy address belongs to the object at ffff888103a3c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 816 bytes inside of freed 2048-byte region [ffff888103a3c000, ffff888103a3c800) Write of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) dlm_put+0x82/0x200 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) kasan_check_range+0x105/0x1b0 (?:?) debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) dlm_put+0x9/0x200 (?:?) debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) full_proxy_release+0x67/0x90 (?:?) __fput+0x1df/0x4b0 (?:?) do_raw_spin_lock+0x10f/0x1b0 (?:?) fput_close_sync+0xd2/0x170 (?:?) __x64_sys_close+0x55/0x90 (?:?) do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87) irqentry_exit+0xac/0x6e0 (?:?) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Freed by task stack: kasan_save_stack+0x33/0x60 (?:?) kasan_save_track+0x14/0x30 (?:?) kasan_save_free_info+0x3b/0x60 (?:?) __kasan_slab_free+0x5f/0x80 (?:?) kfree+0x30f/0x580 (?:?) dlm_put+0x1ce/0x200 (?:?) dlm_unregister_domain+0xf6/0xb30 (?:?) o2cb_cluster_disconnect+0x6b/0x90 (?:?) ocfs2_cluster_disconnect+0x41/0x70 (?:?) ocfs2_dlm_shutdown+0x1c4/0x220 (?:?) ocfs2_dismount_volume+0x38a/0x550 (?:?) generic_shutdown_super+0xc3/0x220 (?:?) kill_block_super+0x29/0x60 (?:?) deactivate_locked_super+0x66/0xe0 (?:?) cleanup_mnt+0x13d/0x210 (?:?) task_work_run+0xfa/0x170 (?:?) exit_to_user_mode_loop+0xd6/0x430 (?:?) do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74349", "url": "https://ubuntu.com/security/CVE-2026-74349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject FITRIM ranges shorter than a cluster ocfs2_trim_mainbm() trims the global bitmap in cluster units, but its too-short range validation only checks sb->s_blocksize. On filesystems with a cluster size larger than the block size, a FITRIM range that is at least one block but shorter than one cluster is accepted and shifted down to len == 0. The later start + len - 1 and len -= ... arithmetic then underflows and can drive trimming past the requested range. Reject ranges shorter than s_clustersize instead. That preserves the existing -EINVAL behavior for requests that cannot discard even one allocation unit and keeps zero-cluster trims out of the group walk.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74351", "url": "https://ubuntu.com/security/CVE-2026-74351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74359", "url": "https://ubuntu.com/security/CVE-2026-74359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs_lookup(): don't leave ->s_dentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74363", "url": "https://ubuntu.com/security/CVE-2026-74363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs commit 4f375ade6aa9 (\"bpf: Avoid RCU context warning when unpinning htab with internal structs\") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.). This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime(). KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags) The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74379", "url": "https://ubuntu.com/security/CVE-2026-74379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax/kmem: account for partial discontiguous resource upon removal When dev_dax_kmem_probe() partially succeeds (at least one range is mapped) but a subsequent range fails request_mem_region() or add_memory_driver_managed(), the probe silently continues, ultimately returning success, but with the corresponding range resource NULL'ed out. dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the underlying resource exists. When remove_memory() is called later, it returns 0 because the memory was never added which causes dev_dax_kmem_remove() to incorrectly assume the (nonexistent) resource can be removed and attempts cleanup on a NULL pointer. Fix this by skipping these ranges altogether, noting that these cases are considered success, such that the cleanup is still reached when all actually-added ranges are successfully removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74382", "url": "https://ubuntu.com/security/CVE-2026-74382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74390", "url": "https://ubuntu.com/security/CVE-2026-74390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr->pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don't overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74395", "url": "https://ubuntu.com/security/CVE-2026-74395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list before initializing the fields used by the shared error path. If eventfd_ctx_fdget() then fails, the unwind path dereferences event_sub->ev_file in uverbs_uobject_put() and calls subscribe_event_xa_dealloc() with an unset xa_key_level1. subscribe_event_xa_alloc() creates the XA entry exactly once for a given key_level1, on the first occurrence of that key. The unwind path must therefore call subscribe_event_xa_dealloc() exactly once for it as well. Enforce that by adding devx_key_in_sub_list() and calling subscribe_event_xa_dealloc() only when the last matching pending entry is being cleaned up.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74399", "url": "https://ubuntu.com/security/CVE-2026-74399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64544", "url": "https://ubuntu.com/security/CVE-2026-64544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents pefile_digest_pe_contents() computes the trailing-data hash length as pelen - (hashed_bytes + certs_size). A crafted PE can make the addition exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB. This is passed to crypto_shash_update() which reads out of bounds and panics on unmapped vmalloc guard pages. BUG: unable to handle page fault for address: ffffc900038d8000 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152) Call Trace: __sha256_update (lib/crypto/sha256.c:208) crypto_sha256_update (crypto/sha256.c:142) verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436) kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151) __do_sys_kexec_file_load (kernel/kexec_file.c:406) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Validate that the addition does not overflow and the result does not exceed pelen before the subtraction. Return -ELIBBAD on failure.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74402", "url": "https://ubuntu.com/security/CVE-2026-74402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix blocking and non-blocking rng logic The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74408", "url": "https://ubuntu.com/security/CVE-2026-74408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: fix OOB access from firmware tx status queue ID ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74410", "url": "https://ubuntu.com/security/CVE-2026-74410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478), causing an out-of-bounds read from the pre-allocated DMA buffer when skb_put_data copies new_len bytes. The USB transport already validates this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the PCIe path does not. Add a check that new_len does not exceed the DMA buffer size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74416", "url": "https://ubuntu.com/security/CVE-2026-74416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix memory leak in radeon_ring_restore() on lock failure radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74424", "url": "https://ubuntu.com/security/CVE-2026-74424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix NULL pointer dereference for a console without vc_data fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data. Keep fb_display[i].mode set only while the console has a vc_data. Check vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74426", "url": "https://ubuntu.com/security/CVE-2026-74426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: fix NULL pointer dereference in afs_get_tree() afs_alloc_sbi() uses kzalloc for memory allocation. And, if ctx->dyn_root is not null, as->cell and as->volume are null. In trace_afs_get_tree() they are dereferenced. KASAN error message: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550 include/trace/events/afs.h:1365 Call Trace: trace_afs_get_tree include/trace/events/afs.h:1365 [inline] afs_get_tree+0x922/0x1350 fs/afs/super.c:599 vfs_get_tree+0x8e/0x300 fs/super.c:1572 do_new_mount fs/namespace.c:3011 [inline] path_mount+0x14a5/0x2220 fs/namespace.c:3341 do_mount fs/namespace.c:3354 [inline] __do_sys_mount fs/namespace.c:3562 [inline] __se_sys_mount fs/namespace.c:3539 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3539 do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74438", "url": "https://ubuntu.com/security/CVE-2026-74438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun4i-ss - Remove insecure and unused rng_alg Remove sun4i_ss_rng, as it is insecure and unused: - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing locking and has a buffer overflow. sun4i_ss_prng_generate() fails to fill the entire buffer with cryptographic random bytes, because it rounds the destination length down and also doesn't actually wait for the hardware to be ready before pulling bytes from it. - No user of this code is known. It's usable only theoretically via the \"rng\" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen and discovered by Atuin - Automated Vulnerability Discovery Engine There's no point in fixing all these vulnerabilities individually when this is unused code, so let's just remove it.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74578", "url": "https://ubuntu.com/security/CVE-2026-74578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_skcipher - force synchronous processing on trees without ctx->state The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx->iv directly into the skcipher request. After io_submit() the socket lock is dropped and the request is processed asynchronously, so a concurrent sendmsg(ALG_SET_IV) can overwrite ctx->iv and make the in-flight request run under an attacker-controlled IV. For CTR/stream modes this is IV/keystream reuse and lets an unprivileged user recover the plaintext of a concurrent operation. Snapshotting ctx->iv into per-request storage for the async path is not sufficient. For ciphers with statesize == 0 - which includes cbc and ctr - the MSG_MORE inter-chunk IV chaining is carried solely by the in-place req->iv writeback, which a snapshot redirects into per-request memory that af_alg_free_resources() releases on completion, silently producing wrong output. Writing the IV back from the completion callback instead is not possible either: that would require lock_sock() there, but the callback can run in softirq/atomic context, so it must not sleep. Make the operation synchronous instead, which removes both the IV race and any writeback race. This is equivalent to the upstream resolution, commit fcc77d33a34c (\"net: Remove support for AIO on sockets\"), which removed the AIO socket path across net/ entirely and so produces the same end state for this file. This patch deviates from that commit deliberately: rather than removing AIO socket support tree-wide, which would be far too invasive for stable, it removes only the AIO branch in crypto/algif_skcipher.c. io_submit() now completes synchronously; AF_ALG async is rarely used in practice. The -EIOCBQUEUED check in skcipher_recvmsg() is now dead but harmless, and is left alone to keep the fix minimal. Tested on 6.6.y: attacker IV injection dropped from 2296/200000 to 0/200000 after the change; MSG_MORE chunked CTR output bit-identical to single-shot.", "cve_priority": "medium", "cve_public_date": "2026-08-16 09:16:00 UTC" }, { "cve": "CVE-2026-64600", "url": "https://ubuntu.com/security/CVE-2026-64600", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.", "cve_priority": "medium", "cve_public_date": "2026-07-23 06:16:00 UTC" }, { "cve": "CVE-2026-64187", "url": "https://ubuntu.com/security/CVE-2026-64187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fail recovery on a committed log item with no regions If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367)", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64266", "url": "https://ubuntu.com/security/CVE-2026-64266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before returning from fuse_ref_folio() fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues. Fix this by locking the request in fuse_ref_folio() before returning.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64268", "url": "https://ubuntu.com/security/CVE-2026-64268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64269", "url": "https://ubuntu.com/security/CVE-2026-64269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64271", "url": "https://ubuntu.com/security/CVE-2026-64271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: touchwin - reset the packet index on every complete packet tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: \ttw->data[tw->idx++] = data; \tif (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { \t\t... \t\ttw->idx = 0; \t} The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64273", "url": "https://ubuntu.com/security/CVE-2026-64273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - bound the device-reported force-feedback effect index iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: \ti = data[1] & 0x7f; \tif (data[1] & 0x80) { \t\tif (!test_and_set_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) \t\t\t... \t} else if (test_and_clear_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) { \t\t... \t} The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate \"effect started/stopped\" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64274", "url": "https://ubuntu.com/security/CVE-2026-64274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: goodix - clamp the device-reported contact count goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer \tu8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: \tts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64275", "url": "https://ubuntu.com/security/CVE-2026-64275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: elan_i2c - prevent division by zero and arithmetic underflow The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64276", "url": "https://ubuntu.com/security/CVE-2026-64276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64277", "url": "https://ubuntu.com/security/CVE-2026-64277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64279", "url": "https://ubuntu.com/security/CVE-2026-64279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter deregistration race Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name).", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64604", "url": "https://ubuntu.com/security/CVE-2026-64604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f No functional change intended.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64296", "url": "https://ubuntu.com/security/CVE-2026-64296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: \tif (++order == 2) \t\tuniname = p_uniname->name; \telse \t\tuniname += EXFAT_FILE_NAME_LEN; \tlen = exfat_extract_uni_name(ep, entry_uniname); \tname_len += len; \tunichar = *(uniname+len); \t*(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba (\"exfat: check if filename entries exceeds max filename length\")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64298", "url": "https://ubuntu.com/security/CVE-2026-64298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: include MAY_WRITE in open permission mask for O_TRUNC POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64299", "url": "https://ubuntu.com/security/CVE-2026-64299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64303", "url": "https://ubuntu.com/security/CVE-2026-64303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64306", "url": "https://ubuntu.com/security/CVE-2026-64306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: drbg - Fix returning success on failure in CTR_DRBG drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64312", "url": "https://ubuntu.com/security/CVE-2026-64312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64313", "url": "https://ubuntu.com/security/CVE-2026-64313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ecc - Fix carry overflow in vli multiplication The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows. The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow. When commit 3c4b23901a0c (\"crypto: ecdh - Add ECDH software support\") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation. Add proper handling for this boundary by accounting for the carry from the lower addition.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64315", "url": "https://ubuntu.com/security/CVE-2026-64315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64316", "url": "https://ubuntu.com/security/CVE-2026-64316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64317", "url": "https://ubuntu.com/security/CVE-2026-64317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge \"SL\" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64318", "url": "https://ubuntu.com/security/CVE-2026-64318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: aix: bound the pp_count scan to the ppe array aix_partition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array: \tint numpps = be16_to_cpu(pvd->pp_count); \t... \tfor (i = 0; i < numpps; i += 1) { \t\tstruct ppe *p = pvd->ppe + i; \t\t... \t\tlp_ix = be16_to_cpu(p->lp_ix); pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk pp_count. pp_count is an unvalidated __be16 read straight from the descriptor, so a crafted AIX image with pp_count larger than 1016 drives the loop to read pvd->ppe[i] past the end of the allocation (up to 65535 entries, ~2 MB out of bounds). The partition scan runs without mounting anything, when a block device with a crafted AIX/IBM partition table appears (an attacker-supplied image attached with losetup -P, or a device auto-scanned by udev), via msdos_partition() -> aix_partition(). Clamp the scan to the number of entries the ppe[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64322", "url": "https://ubuntu.com/security/CVE-2026-64322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when \tsizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: \tfor (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) { \t\tstruct sparingEntry *entry = &st->mapEntry[i]; \t\t... entry->origLocation ... \t} in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64323", "url": "https://ubuntu.com/security/CVE-2026-64323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate VAT header length against the VAT inode size udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size: \tmap->s_type_specific.s_virtual.s_start_offset = \t\tle16_to_cpu(vat20->lengthHeader); \tmap->s_type_specific.s_virtual.s_num_entries = \t\t(sbi->s_vat_inode->i_size - \t\t\tmap->s_type_specific.s_virtual.s_start_offset) >> 2; lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the \"block > s_num_entries\" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads \t((__le32 *)(iinfo->i_data + s_start_offset))[block] so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read. Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64324", "url": "https://ubuntu.com/security/CVE-2026-64324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate free block extents against the partition length udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64330", "url": "https://ubuntu.com/security/CVE-2026-64330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64331", "url": "https://ubuntu.com/security/CVE-2026-64331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running `usbip attach` from the host would cause the guest to oops with the following backtrace: Call trace: vep_dequeue+0x1c/0xe4 (P) usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34 __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64332", "url": "https://ubuntu.com/security/CVE-2026-64332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ulpi: fix memory leak on registration failure The allocated device name is never freed on early ULPI device registration failures. Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64333", "url": "https://ubuntu.com/security/CVE-2026-64333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64334", "url": "https://ubuntu.com/security/CVE-2026-64334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix hard lockup on disconnect If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled. Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect. This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64335", "url": "https://ubuntu.com/security/CVE-2026-64335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix broken rx after throttle If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound). Clear the throttle flags and submit the urb if needed when opening the port.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64336", "url": "https://ubuntu.com/security/CVE-2026-64336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan_pda: fix information leak The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspan_pda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer. Fix the information leak by making sure that keyspan_pda_write_start() returns zero on success as intended.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64337", "url": "https://ubuntu.com/security/CVE-2026-64337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: unmap request DMA on queue failure mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails. Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64338", "url": "https://ubuntu.com/security/CVE-2026-64338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: misc: uss720: unregister parport on probe failure uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered. Leaving the port registered is more than a private allocation leak: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is about to release. Undo the pre-announce registration in the get_1284_register() failure branch before jumping to the common private-data cleanup path. Clear priv->pp first, matching the disconnect path and avoiding a stale pointer in the private data. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64340", "url": "https://ubuntu.com/security/CVE-2026-64340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: legousbtower: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64342", "url": "https://ubuntu.com/security/CVE-2026-64342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: iowarrior: fix use-after-free on disconnect Submitted write URBs are not stopped on close() and therefore need to be stopped unconditionally on disconnect() to avoid use-after-free in the completion handler.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64343", "url": "https://ubuntu.com/security/CVE-2026-64343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ldusb: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64344", "url": "https://ubuntu.com/security/CVE-2026-64344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64346", "url": "https://ubuntu.com/security/CVE-2026-64346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: Fix use-after-free in gadget_match_driver The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usb_del_gadget() frees the udc memory (e.g., via mode-switch work) while gadget_match_driver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed: [39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr : gadget_match_driver+0x34/0x60 ... [39430.911890][ T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][ T1171] Workqueue: events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usb_gadget_release() routine to the core. When the gadget is added, usb_add_gadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usb_gadget_release() drops the reference to the udc and then calls the gadget's release routine.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64347", "url": "https://ubuntu.com/security/CVE-2026-64347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler The OTG branch of composite_setup() falls back to the first configuration when none is selected: \tif (cdev->config) \t\tconfig = cdev->config; \telse \t\tconfig = list_first_entry(&cdev->configs, \t\t\t\t\t struct usb_configuration, list); \tif (!config) \t\tgoto done; \t... \tmemcpy(req->buf, config->descriptors[0], value); list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the \"if (!config)\" check is dead. When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer. cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch. Use list_first_entry_or_null() so the existing check does its job.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64350", "url": "https://ubuntu.com/security/CVE-2026-64350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info() cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and stream_rings array, but leaves stream_ctx_array allocated. Free the stream context array before falling through to the stream_rings cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64351", "url": "https://ubuntu.com/security/CVE-2026-64351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: bound RX frame length in kalmia_rx_fixup() kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usb_packet_length to about 65530. That bypasses the usb_packet_length < ether_packet_length truncation path. The device-supplied ether_packet_length, a le16 up to 65535 read from header_start[2], then drives a memcmp() and the following skb_trim() and skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10, which is 14000 bytes. That is an out of bounds read. Require both the start and end framing headers to be present before subtracting them, on every loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64359", "url": "https://ubuntu.com/security/CVE-2026-64359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64360", "url": "https://ubuntu.com/security/CVE-2026-64360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64362", "url": "https://ubuntu.com/security/CVE-2026-64362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: lg-g15: cancel pending work on remove to fix a use-after-free lg_g15_data is allocated with devm and holds a work item. The report handlers schedule that work straight from device input. lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key, and lg_g510_leds_event() does it too. The worker dereferences the lg_g15_data back through container_of. The driver had no remove callback and never cancelled the work. So if a report scheduled the work and the keyboard was then unplugged, devres freed lg_g15_data while the work was still pending or running, and the worker touched freed memory. This is a use-after-free. It is reachable as a race on device unplug. Add a remove callback that cancels the work before devres frees the state. g15->work is only initialized for the models that schedule it (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the cancel on g15->work.func to avoid cancelling a work that was never set up. The g15 NULL test mirrors the one already in lg_g15_raw_event().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68091", "url": "https://ubuntu.com/security/CVE-2026-68091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: stop hardware after post-start probe failures wacom_parse_and_register() starts HID hardware before registering inputs and initializing pad LEDs/remotes. Those later steps can fail, but their error paths currently release Wacom resources without stopping the HID hardware. Route post-hid_hw_start() failures through hid_hw_stop() before releasing driver resources. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64370", "url": "https://ubuntu.com/security/CVE-2026-64370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference via get_pid() and stores it in timer.it.cpu.pid. If the subsequent posix_cpu_timer_set() call fails, the function returns immediately without calling posix_cpu_timer_del() to release the pid reference, causing a leak. Fix it by calling posix_cpu_timer_del() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64372", "url": "https://ubuntu.com/security/CVE-2026-64372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: pcc: fix use-after-free and double free in _OSC evaluation pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the two-phase _OSC negotiation. Between the two calls it freed output.pointer but left output.length unchanged. Since acpi_evaluate_object() treats a non-zero length with a non-NULL pointer as an existing buffer to write into, the second call wrote into freed memory (use-after-free). The subsequent kfree(output.pointer) at out_free then freed the same pointer a second time (double free). Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first result, so ACPICA allocates a fresh buffer for each phase independently.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64373", "url": "https://ubuntu.com/security/CVE-2026-64373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path. Unlike the normal system suspend path, the reboot path does not call freeze_processes(), so userspace processes and kernel threads remain active. This allows CPU hotplug operations to run concurrently with cpufreq_suspend(). The original code has no synchronization with CPU hotplug, leading to a race condition where governor_data can be freed by the hotplug path while cpufreq_suspend() is still accessing it, resulting in a null pointer dereference: Unable to handle kernel NULL pointer dereference Call Trace: do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200 Fix this by adding cpus_read_lock()/cpus_read_unlock() to cpufreq_suspend() to block CPU hotplug operations while suspend is in progress. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64374", "url": "https://ubuntu.com/security/CVE-2026-64374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64403", "url": "https://ubuntu.com/security/CVE-2026-64403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64408", "url": "https://ubuntu.com/security/CVE-2026-64408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: pin L2CAP connection during netdev registration bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64411", "url": "https://ubuntu.com/security/CVE-2026-64411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: terminate table name before find_table_lock() update_counters() and compat_update_counters() forward a user-supplied 32-byte table name to find_table_lock() without NUL-terminating it. On a lookup miss, find_inlist_lock() calls try_then_request_module(..., \"%s%s\", \"ebtable_\", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte. BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) __request_module (kernel/module/kmod.c:150) do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) update_counters (net/bridge/netfilter/ebtables.c:1440) do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573) nf_setsockopt (net/netfilter/nf_sockopt.c:101) ip_setsockopt (net/ipv4/ip_sockglue.c:1424) raw_setsockopt (net/ipv4/raw.c:847) __sys_setsockopt (net/socket.c:2393) ... compat_do_replace() shares the same unterminated name via compat_copy_ebt_replace_from_user(); terminate it there too so all find_table_lock() callers behave alike. The other callers already terminate the name after the copy.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64412", "url": "https://ubuntu.com/security/CVE-2026-64412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: module names must be null-terminated We need to explicitly check the length, else we may pass non-null terminated string to request_module().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64420", "url": "https://ubuntu.com/security/CVE-2026-64420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: cros_ec: Delay dev_set_drvdata() until probe success If ec_device_probe() fails, cros_ec_class_release releases memory for the cros_ec_dev structure. However, because the drvdata was already set, sub-drivers like cros_ec_typec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when cros_ec_typec attempts to access &typec->ec->ec->dev on a device that has already been released. Move dev_set_drvdata() to ensure that the pointer is only made available once all initialization steps have succeeded. sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' Call trace: sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... BUG: KASAN: invalid-access in __memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOT_MODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: events_unbound deferred_probe_work_func Call trace: __memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64422", "url": "https://ubuntu.com/security/CVE-2026-64422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP socket state. The sysctl is stored as an `int` but copied into the `u32` `tp->reordering` field for new sockets, so negative writes wrap to large values. With `tcp_mtu_probing=2`, the wrapped value can overflow the `tcp_mtu_probe()` size calculation and drive the MTU probing path into an out-of-bounds read. Route `tcp_reordering` writes through `proc_dointvec_minmax()` and require it to be at least 1. Also require `tcp_max_reordering` to be at least 1 so the configured maximum cannot become negative either. When registering the table for a non-init network namespace, relocate `extra2` pointers that refer into `init_net.ipv4` so the `tcp_reordering` upper bound follows that namespace's `tcp_max_reordering`. Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`. This keeps the send queue and window checks from being bypassed through signed integer overflow.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64423", "url": "https://ubuntu.com/security/CVE-2026-64423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: remove multicast group from hash table on device destruction When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through the multicast list and calls ip_ma_put() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mc_hash). Since the device remains published in dev->ip_ptr until after ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs. Fix this by unlinking the multicast group from mc_hash using ip_mc_hash_remove() before scheduling it for reclamation. BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276 Call Trace: dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 Allocated by task 2239: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40 __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300 Freed by task 0: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50 __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64425", "url": "https://ubuntu.com/security/CVE-2026-64425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 10dc95939817 (\"io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64429", "url": "https://ubuntu.com/security/CVE-2026-64429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: eic-sprd: use raw_spinlock_t in the irq startup path sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64430", "url": "https://ubuntu.com/security/CVE-2026-64430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid calling pci_irq_vector() from hardirq context ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive the vector number. pci_irq_vector() calls msi_get_virq() that takes a mutex and can therefore trigger \"scheduling while atomic\" splats: BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedule_preempt_disabled+0x28/0x50 __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf] __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64432", "url": "https://ubuntu.com/security/CVE-2026-64432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns In the analysis pass of $LogFile journal replay, log_replay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcns_follow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time: BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array: 1. dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow. 2. lrh->target_vcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge size_t. Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL. This mirrors the bounds-check pattern added in commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") and commit 0ca0485e4b2e (\"fs/ntfs3: validate rec->used in journal-replay file record check\").", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68090", "url": "https://ubuntu.com/security/CVE-2026-68090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) \treturn; obj = alloc(); \t\t\t\tif (!obj) { \t\t\t\t\t\t\t// Out of memory \tdebug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized \tif (!IS_ERR_OR_NULL(obj)) \treturn; if (!obj) { \tdebug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64435", "url": "https://ubuntu.com/security/CVE-2026-64435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: Fix data races of skb_queue_len() readers on audit_queue Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races. All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn() KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 value changed: 0x00000001 -> 0x00000000 ================================================================== Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side. [PM: line length tweak]", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64436", "url": "https://ubuntu.com/security/CVE-2026-64436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: initialize alg_key_len for IPComp states pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name: \tx->calg = kmalloc_obj(*x->calg); \tif (!x->calg) { \t\terr = -ENOMEM; \t\tgoto out; \t} \tstrcpy(x->calg->alg_name, a->name); \tx->props.calgo = sa->sadb_sa_encrypt; Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data. calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE: \txfrm_state_migrate() \t xfrm_state_clone_and_setup() \t x->calg = xfrm_algo_clone(orig->calg); \t kmemdup(orig, xfrm_alg_len(orig)); where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0): BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90 ___sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4) Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail. The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent. Initialize calg->alg_key_len to 0, matching the aalg/ealg branches.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64599", "url": "https://ubuntu.com/security/CVE-2026-64599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: amlogic - avoid double cleanup in meson_crypto_probe() When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker(). Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM. ================================================================== BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0 Read of size 8 at addr ff1100010c057a68 by task insmod/265 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? kthread_destroy_worker+0xb2/0xd0 ? kthread_destroy_worker+0xb2/0xd0 kasan_report+0xca/0x100 ? kthread_destroy_worker+0xb2/0xd0 kthread_destroy_worker+0xb2/0xd0 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto] platform_probe+0x99/0x140 really_probe+0x1c6/0x6a0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x248/0x310 ? acpi_driver_match_device+0xb0/0x100 driver_probe_device+0x48/0x210 ? __pfx___device_attach_driver+0x10/0x10 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x104/0x190 ? __pfx_bus_for_each_drv+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 __device_attach+0x19d/0x3b0 ? __pfx___device_attach+0x10/0x10 ? do_raw_spin_unlock+0x53/0x220 device_initial_probe+0x78/0xa0 bus_probe_device+0x5b/0x130 device_add+0xcfd/0x1430 ? __pfx_device_add+0x10/0x10 ? insert_resource+0x34/0x50 ? lock_release+0xc9/0x290 platform_device_add+0x24e/0x590 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro] meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro] do_one_initcall+0xc0/0x450 ? __pfx_do_one_initcall+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 ? __create_object+0x59/0x80 ? kasan_unpoison+0x27/0x60 do_init_module+0x27b/0x7d0 ? __pfx_do_init_module+0x10/0x10 ? kasan_quarantine_put+0x84/0x1d0 ? kfree+0x32c/0x510 ? load_module+0x561e/0x5ff0 load_module+0x54fe/0x5ff0 ? __pfx_load_module+0x10/0x10 ? security_file_permission+0x20/0x40 ? kernel_read_file+0x23d/0x6e0 ? mmap_region+0x235/0x4a0 ? __pfx_kernel_read_file+0x10/0x10 ? __file_has_perm+0x2c0/0x3e0 init_module_from_file+0x158/0x180 ? __pfx_init_module_from_file+0x10/0x10 ? __lock_acquire+0x45a/0x1ba0 ? idempotent_init_module+0x315/0x610 ? lock_release+0xc9/0x290 ? lock ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64440", "url": "https://ubuntu.com/security/CVE-2026-64440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB write in HT_caps_handler() HT_caps_handler() iterates pIE->length bytes and writes into HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct HT_caps_element). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlme_ext_info. Truncate the iteration count to the size of HT_caps.u.HT_cap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HT_caps_enable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64536", "url": "https://ubuntu.com/security/CVE-2026-64536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop The loop in is_ap_in_tkip() iterates over IEs without verifying that enough bytes remain before dereferencing the IE header or its payload: - pIE->element_id and pIE->length are read without checking that i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the buffer causes an OOB read. - For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12, which requires pIE->length >= 16. For WLAN_EID_RSN it compares pIE->data + 8, requiring pIE->length >= 12. Neither requirement is checked. Add the missing IE header and payload bounds checks and guard each data access with an explicit pIE->length minimum, matching the pattern established in update_beacon_info().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-64442", "url": "https://ubuntu.com/security/CVE-2026-64442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64443", "url": "https://ubuntu.com/security/CVE-2026-64443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the element_id byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64444", "url": "https://ubuntu.com/security/CVE-2026-64444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i < pkt_len. When a malicious AP sends an AssocResponse whose last IE has only one byte remaining in the frame (the element_id byte lands at pkt_len-1), the loop reads pIE->length from pframe[pkt_len], which is one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pkt_len, silently passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pkt_len.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64445", "url": "https://ubuntu.com/security/CVE-2026-64445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth() OnAuth() has two bugs in the shared-key authentication path. When the Privacy bit is set, rtw_wep_decrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtw_wep_decrypt(), length is computed as: length = len - WLAN_HDR_A3_LEN - iv_len and then passed as (length - 4) to crc32_le(). If len is less than WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative and, after the implicit cast to size_t, causes crc32_le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path. When processing a seq=3 response, rtw_get_ie() stores the Challenge Text IE length in ie_len, but the subsequent memcmp() always reads 128 bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64450", "url": "https://ubuntu.com/security/CVE-2026-64450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it (\"if (glen > dlen) break;\"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: \tthis_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), \t\t\t GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: \"if (glen > dlen) break;\" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means \"legacy peer without Selective ACK\", a distinct legitimate state.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64452", "url": "https://ubuntu.com/security/CVE-2026-64452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix NHC entry use-after-free on error path lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding lowpan_nhc_lock. If the descriptor has no uncompress callback, the error path drops the lock before printing nhc->name. lowpan_nhc_del() removes descriptors under the same lock and then relies on synchronize_net() before the owning module can be unloaded. That only waits for net RX RCU readers. lowpan_header_decompress() is also exported and can be reached from callers that are not necessarily covered by the net core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive path. This leaves a race where one task drops lowpan_nhc_lock in the error path, another task unregisters and frees the matching descriptor after synchronize_net() returns, and the first task then dereferences nhc->name for the warning. With the post-unlock window widened, KASAN reports: BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220 Read of size 8 lowpan_nhc_do_uncompression lowpan_header_decompress Fix this by printing the warning before dropping lowpan_nhc_lock, so the descriptor name is read while unregister is still excluded. The malformed packet is still rejected with -ENOTSUPP.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64454", "url": "https://ubuntu.com/security/CVE-2026-64454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: run gadget disconnect from sleepable suspend context dwc3_gadget_suspend() takes dwc->lock with IRQs disabled and then calls dwc3_disconnect_gadget(). For async callbacks that helper only uses plain spin_unlock()/spin_lock(), so the gadget ->disconnect() callback still runs with IRQs disabled and any sleepable callback trips Lockdep. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the dwc3_gadget_suspend() -> dwc3_disconnect_gadget() -> gadget_driver->disconnect() chain, and Lockdep reported: BUG: sleeping function called from invalid context gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] Keep the disconnect callback selection in one common helper, but add a sleepable suspend-side wrapper which snapshots the callback under dwc->lock and then runs it after spin_unlock_irqrestore(). The regular event path still uses the existing spin_unlock()/spin_lock() window.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64455", "url": "https://ubuntu.com/security/CVE-2026-64455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: chaoskey: Fix slab-use-after-free in chaoskey_release() The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: \tBUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) \tRead of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 \tHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 \tCall Trace: \t \t dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) \t print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) \t kasan_report (mm/kasan/report.c:595) \t dev_driver_string (drivers/base/core.c:2406) \t __dynamic_dev_dbg (lib/dynamic_debug.c:906) \t chaoskey_release (drivers/usb/misc/chaoskey.c:323) \t __fput (fs/file_table.c:510) \t fput_close_sync (fs/file_table.c:615) \t __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) \t do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) \t entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64456", "url": "https://ubuntu.com/security/CVE-2026-64456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: virtio: clamp device-reported used.len at copy_data() random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64189", "url": "https://ubuntu.com/security/CVE-2026-64189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64465", "url": "https://ubuntu.com/security/CVE-2026-64465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix sleep in atomic context in xhci_free_streams() When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64468", "url": "https://ubuntu.com/security/CVE-2026-64468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_free_transaction() In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64469", "url": "https://ubuntu.com/security/CVE-2026-64469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_thread_release() When a thread exits, binder_thread_release() walks its transaction stack to clear the t->from and t->to_proc that correspond with the exiting thread. However, a process dying in parallel might attempt to kfree some of these transactions. And if one of them has no associated t->to_proc, the t->to_proc->inner_lock will not be acquired. This means that transaction accesses in binder_thread_release() after t->to_proc has been cleared might race with binder_free_transaction() and cause a use-after-free error as reported by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798 Write of size 8 at addr ffff000016627500 by task X/715 CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...] Allocated by task 717 on cpu 18 at 67.267803s: __kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+0x554/0x8150 binder_thread_write+0xa30/0x4354 binder_ioctl+0x20f0/0x299c [...] Freed by task 202 on cpu 18 at 90.416221s: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_free_transaction+0x150/0x294 binder_send_failed_reply+0x398/0x6d8 binder_release_work+0x3e4/0x4ec binder_deferred_func+0xbd8/0x104c [...] ================================================================== In order to avoid this, make sure that binder_free_transaction() reads the t->to_proc under the transaction lock. This will serialize the transaction release with the accesses in binder_thread_release(). Plus, it matches the documented locking rules for @to_proc.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64470", "url": "https://ubuntu.com/security/CVE-2026-64470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on marvell probe failure Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64471", "url": "https://ubuntu.com/security/CVE-2026-64471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on registration failure Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64478", "url": "https://ubuntu.com/security/CVE-2026-64478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64483", "url": "https://ubuntu.com/security/CVE-2026-64483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. \tcount = be32_to_cpu(payload->sample_count); \tif (likely(count <= (length - 16) / 4)) \t\tisight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64484", "url": "https://ubuntu.com/security/CVE-2026-64484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es1938: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. snd_es1938_mixer() does not check the return value before dereferencing the pointer, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64487", "url": "https://ubuntu.com/security/CVE-2026-64487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every iteration it advances buf and subtracts the block size while looping on \"while (len)\". len is urb->actual_length. That value is supplied by the device and is not guaranteed to be a multiple of 16. When a final short block leaves len between 1 and 15, the loop runs once more, reads up to buf[15], and then does \"len -= TKS4_MSGBLOCK_SIZE\". As len is unsigned this underflows to a huge value. The loop then keeps iterating and walking buf far past the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus block id happens to be hit. Iterate only while a full message block is available. This stops the unsigned underflow and silently drops any trailing partial block, which carries no complete control value anyway. The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1 and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor urb->actual_length before dispatching.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64494", "url": "https://ubuntu.com/security/CVE-2026-64494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: fix runtime PM leak on read error gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the \"out\" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a \"goto out\" to ensure the reference is properly dropped on the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64495", "url": "https://ubuntu.com/security/CVE-2026-64495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: bmg160: bail out when bandwidth/filter is not in table bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: \tfor (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { \t\tif (bmg160_samp_freq_table[i].bw_bits == bw_bits) \t\t\tbreak; \t} \t*val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64496", "url": "https://ubuntu.com/security/CVE-2026-64496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64497", "url": "https://ubuntu.com/security/CVE-2026-64497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64602", "url": "https://ubuntu.com/security/CVE-2026-64602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: spear: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in spear_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, spear_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ spear_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64500", "url": "https://ubuntu.com/security/CVE-2026-64500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: lpc32xx: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64503", "url": "https://ubuntu.com/security/CVE-2026-64503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64504", "url": "https://ubuntu.com/security/CVE-2026-64504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer \tu16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: \tcount = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: \tif (samples && count > samples) \t\tcount = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: \tbmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64505", "url": "https://ubuntu.com/security/CVE-2026-64505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check for header Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68088", "url": "https://ubuntu.com/security/CVE-2026-68088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check to response query Add variable representations for BufLength and BufOffset in rndis_query_response(), and perform a length check on them. This is identical to how rndis_set_response() handles these parameters.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-53392", "url": "https://ubuntu.com/security/CVE-2026-53392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53402", "url": "https://ubuntu.com/security/CVE-2026-53402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font() When fbcon_do_set_font() fails (e.g., due to a memory allocation failure inside vc_resize() under heavy memory pressure), it jumps to the `err_out` label to roll back the console state. However, the current rollback logic forgets to restore the `hi_font` state, leading to a severe state machine corruption. Earlier in the function, `set_vc_hi_font()` might be called to change `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()` subsequently fails, the `err_out` path restores `vc_font.charcount` but entirely skips rolling back the `vc_hi_font_mask` and the screen buffer. This mismatch leaves the terminal in a desynchronized state. Because `vc_hi_font_mask` remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure. Fix this by adding the missing rollback logic for the `hi_font` mask and screen buffer in the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63810", "url": "https://ubuntu.com/security/CVE-2026-63810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Avoid mounting the bdev pseudo-filesystem in userspace The bdev pseudo-filesystem is an internal kernel filesystem with which userspace should not interfere. Unregister it so that userspace cannot even attempt to mount it. This fixes a bug [1] that occurs when attempting to access files, because the system call move_mount() uses pointers declared in the inode_operations structure, which for the bdev pseudo-filesystem are always equal to 0. `inode->i_op = &empty_iops;` [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:0x0 Call Trace: lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460 open_last_lookups fs/namei.c:3550 [inline] path_openat+0x953/0x2700 fs/namei.c:3780 do_filp_open+0x1c5/0x410 fs/namei.c:3810 do_sys_openat2+0x171/0x4d0 fs/open.c:1318 do_sys_open fs/open.c:1334 [inline] __do_sys_openat fs/open.c:1350 [inline] __se_sys_openat fs/open.c:1345 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68459", "url": "https://ubuntu.com/security/CVE-2026-68459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs() When we mount device w/ gc_merge mount option, we may suffer below potential deadlock: Kworker\t\t\t\t\tGC trehad\t\t\tTruncator - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback --- set writeback flag on folio - f2fs_outplace_write_data : cached folio in internal bio cache - f2fs_balance_fs - wake_up(gc_thread) : wake up gc thread to run foreground GC - finish_wait(fggc_wq) : wait on the waitqueue --- wait on GC thread to finish the work \t\t\t\t\t\t\t\t\t- truncate_inode_pages_range \t\t\t\t\t\t\t\t\t - __filemap_get_folio(, FGP_LOCK) --- lock folio \t\t\t\t\t\t\t\t\t - truncate_inode_partial_folio \t\t\t\t\t\t\t\t\t - folio_wait_writeback --- wait on writeback being cleared \t\t\t\t\t- do_garbage_collect \t\t\t\t\t - move_data_page \t\t\t\t\t - f2fs_get_lock_data_folio \t\t\t\t\t - lock on folio --- blocked on folio's lock In order to avoid such deadlock, let's call below functions to commit cached bios in GC_MERGE path of f2fs_balance_fs() as the same as we did in NOGC_MERGE path. - f2fs_submit_merged_write(sbi, DATA); - f2fs_submit_all_merged_ipu_writes(sbi);", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-68460", "url": "https://ubuntu.com/security/CVE-2026-68460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in f2fs_balance_fs() When the f2fs filesystem space is nearly exhausted, we encounter deadlock issues as below: INFO: task A:1890 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:A state:D stack:0 pid:1890 tgid:1626 ppid:1153 flags:0x00000204 Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 folio_wait_bit+0x20/0x38 folio_wait_writeback+0x54/0xc8 truncate_inode_partial_folio+0x70/0x1e0 truncate_inode_pages_range+0x1b0/0x450 truncate_pagecache+0x54/0x88 f2fs_file_write_iter+0x3e8/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task kworker/u8:11:2680853 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:11 state:D stack:0 pid:2680853 tgid:2680853 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 __filemap_get_folio+0x214/0x348 pagecache_get_page+0x20/0x70 f2fs_get_read_data_page+0x150/0x3e8 f2fs_get_lock_data_page+0x2c/0x160 move_data_page+0x50/0x478 do_garbage_collect+0xd38/0x1528 f2fs_gc+0x240/0x7e0 f2fs_balance_fs+0x1a0/0x208 f2fs_write_single_data_page+0x6e4/0x730 f2fs_write_cache_pages+0x378/0x9b0 f2fs_write_data_pages+0x2e4/0x388 do_writepages+0x8c/0x2c8 __writeback_single_inode+0x4c/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x200 INFO: task kworker/u8:8:2641297 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:8 state:D stack:0 pid:2641297 tgid:2641297 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_write_inode+0xf4/0x328 __writeback_single_inode+0x370/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x20 INFO: task B:1902 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:B state:D stack:0 pid:1902 tgid:1626 ppid:1153 flags:0x0000020c Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_map_blocks+0x94c/0x1110 f2fs_file_write_iter+0x228/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task sync:2769849 blocked for more than 120 seconds. Tainted: G ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63815", "url": "https://ubuntu.com/security/CVE-2026-63815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: bound i_inline_xattr_size for non-inline-xattr inodes When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: \tif (f2fs_sb_has_flexible_inline_xattr(sbi)) \t\tfi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: \tMAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) \tNR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) \taddrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: \twhile (bit_pos < d->max)\t\t/* fs/f2fs/dir.c */ \t\t... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ... Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files. Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63818", "url": "https://ubuntu.com/security/CVE-2026-63818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate orphan inode entry count f2fs_recover_orphan_inodes() trusts the orphan block entry_count when replaying orphan inodes from the checkpoint pack. A corrupted entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the ino[] array and interpret footer or following data as inode numbers. On a crafted image, mounting an unpatched kernel can drive orphan recovery into f2fs_bug_on() and panic the kernel. Validate entry_count before consuming entries so corrupted checkpoint data fails the mount with -EFSCORRUPTED and requests fsck instead. Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be recorded in the superblock s_errors[] field. This gives fsck a persistent hint even though mount-time orphan recovery failure may leave no chance to persist SBI_NEED_FSCK through a checkpoint.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68461", "url": "https://ubuntu.com/security/CVE-2026-68461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device property: initialize the remaining fields of fwnode_handle in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitialized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. While at it: initialize the remaining fields of struct fwnode_handle too just to be sure. [ Fix typo in commit message. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63829", "url": "https://ubuntu.com/security/CVE-2026-63829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper. Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs. Commit 8b484efd5cb4 (\"ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\") added the same check on the ioctl path. This adds it on RTM_NEWLINK.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2022-3114", "url": "https://ubuntu.com/security/CVE-2022-3114", "cve_description": "An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference.", "cve_priority": "negligible", "cve_public_date": "2022-12-14 21:15:00 UTC" }, { "cve": "CVE-2026-64514", "url": "https://ubuntu.com/security/CVE-2026-64514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is \"is this fault still WP-blocked?\". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says \"wait\", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns \"don't wait\" and lets the fault path retry.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53399", "url": "https://ubuntu.com/security/CVE-2026-53399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: release layout stid on setlease failure nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "high", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-31451", "url": "https://ubuntu.com/security/CVE-2026-31451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption. The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-43355", "url": "https://ubuntu.com/security/CVE-2026-43355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: bh1780: fix PM runtime leak on error path Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53139", "url": "https://ubuntu.com/security/CVE-2026-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23364", "url": "https://ubuntu.com/security/CVE-2026-23364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Compare MACs in constant time To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-46208", "url": "https://ubuntu.com/security/CVE-2026-46208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2023-54271", "url": "https://ubuntu.com/security/CVE-2023-54271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init blk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This happens because iocg->ioc is NULL. The field is initialized by ioc_pd_init() and never cleared. The NULL deref is caused by blkcg_activate_policy() installing blkg_policy_data before initializing it. blkcg_activate_policy() was doing the following: 1. Allocate pd's for all existing blkg's and install them in blkg->pd[]. 2. Initialize all pd's. 3. Online all pd's. blkcg_activate_policy() only grabs the queue_lock and may release and re-acquire the lock as allocation may need to sleep. ioc_weight_write() grabs blkcg->lock and iterates all its blkg's. The two can race and if ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a pd which is not initialized yet, leading to crash. The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c \"echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos\" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weight with the following patch applied: > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index fc49be622e05..38d671d5e10c 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol) > \t\tpd->online = false; > \t} > > + if (system_state == SYSTEM_RUNNING) { > + spin_unlock_irq(&q->queue_lock); > + ssleep(1); > + spin_lock_irq(&q->queue_lock); > + } > + > \t/* all allocated, init in the same order */ > \tif (pol->pd_init_fn) > \t\tlist_for_each_entry_reverse(blkg, &q->blkg_list, q_node) I don't see a reason why all pd's should be allocated, initialized and onlined together. The only ordering requirement is that parent blkgs to be initialized and onlined before children, which is guaranteed from the walking order. Let's fix the bug by allocating, initializing and onlining pd for each blkg and holding blkcg->lock over initialization and onlining. This ensures that an installed blkg is always fully initialized and onlined removing the the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53189", "url": "https://ubuntu.com/security/CVE-2026-53189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-52918", "url": "https://ubuntu.com/security/CVE-2026-52918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46160", "url": "https://ubuntu.com/security/CVE-2026-46160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix missing last_unlink_trans update when removing a directory When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path \"/mnt/dir1\" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] \t\tinode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] \t\trdev 0 sequence 2 flags 0x0 [445771.638102] \t\tatime 1775744884.0 [445771.660056] \t\tctime 1775744885.645502983 [445771.660058] \t\tmtime 1775744885.645502983 [445771.660060] \t\totime 1775744884.0 [445771.660062] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] \t\tindex 0 name_len 2 [445771.660066] \titem 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] \t\tlocation key (259 1 0) type 2 [445771.660070] \t\ttransid 9 data_len 0 name_len 4 [445771.660075] \titem 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] \t\tlocation key (257 1 0) type 2 [445771.660077] \t\ttransid 9 data_len 0 name_len 4 [445771.660078] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] \t\tlocation key (257 1 0) type 2 [445771.660080] \t\ttransid 9 data_len 0 name_len 4 [445771.660081] \titem 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] \t\tlocation key (259 1 0) type 2 [445771.660083] \t\ttransid 9 data_len 0 name_len 4 [445771.660084] \titem 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] \t\tinode generation 9 transid 9 size 8 nbytes 0 [445771.660087] \t\tblock group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] \t\trdev 0 sequence 2 flags 0x0 [445771.660089] \t\tatime 1775744885.641174097 [445771.660090] \t\tctime 1775744885.645502983 [445771.660091] \t\tmtime 1775744885.645502983 [445771.660105] \t\totime 1775744885.641174097 [445771.660106] \titem 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] \t\tindex 2 name_len 4 [445771.660108] \titem 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] \t\tlocation key (2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46292", "url": "https://ubuntu.com/security/CVE-2026-46292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46159", "url": "https://ubuntu.com/security/CVE-2026-46159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46191", "url": "https://ubuntu.com/security/CVE-2026-46191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46116", "url": "https://ubuntu.com/security/CVE-2026-46116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: \tif (x->km.seq) \t\thlist_del_rcu(&x->byseq); \tif (x->id.spi) \t\thlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46193", "url": "https://ubuntu.com/security/CVE-2026-46193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46180", "url": "https://ubuntu.com/security/CVE-2026-46180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31709", "url": "https://ubuntu.com/security/CVE-2026-31709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-46196", "url": "https://ubuntu.com/security/CVE-2026-46196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46291", "url": "https://ubuntu.com/security/CVE-2026-46291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46090", "url": "https://ubuntu.com/security/CVE-2026-46090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 (\"ALSA: aloop: Fix racy access at PCM trigger\") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46052", "url": "https://ubuntu.com/security/CVE-2026-46052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are unhashed Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume \"negative\" also means \"unhashed\": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45999", "url": "https://ubuntu.com/security/CVE-2026-45999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: \"outpages - inpages\" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46103", "url": "https://ubuntu.com/security/CVE-2026-46103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46056", "url": "https://ubuntu.com/security/CVE-2026-46056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46299", "url": "https://ubuntu.com/security/CVE-2026-46299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: \t========================= \tWARNING: held lock freed! \t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted \t------------------------- \tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! \tffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \t2 locks held by mount/174: \t#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 \t#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \tstack backtrace: \tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tCall Trace: \t \tdump_stack_lvl+0x82/0xd0 \tdebug_check_no_locks_freed+0x13a/0x180 \tkfree+0x16b/0x510 \t? hfsplus_fill_super+0xcb4/0x18a0 \thfsplus_fill_super+0xcb4/0x18a0 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x65f/0xc30 \t? srso_return_thunk+0x5/0x5f \t? pointer+0x4ce/0xbf0 \t? trace_contention_end+0x11c/0x150 \t? __pfx_pointer+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x79b/0xc30 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? vsnprintf+0x6da/0x1270 \t? srso_return_thunk+0x5/0x5f \t? __mutex_unlock_slowpath+0x157/0x740 \t? __pfx_vsnprintf+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? mark_held_locks+0x49/0x80 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? irqentry_exit+0x17b/0x5e0 \t? trace_irq_disable.constprop.0+0x116/0x150 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? __pfx_hfsplus_fill_super+0x10/0x10 \tget_tree_bdev_flags+0x302/0x580 \t? __pfx_get_tree_bdev_flags+0x10/0x10 \t? vfs_parse_fs_qstr+0x129/0x1a0 \t? __pfx_vfs_parse_fs_qstr+0x3/0x10 \tvfs_get_tree+0x89/0x320 \tfc_mount+0x10/0x1d0 \tpath_mount+0x5c5/0x21c0 \t? __pfx_path_mount+0x10/0x10 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? kmem_cache_free+0x307/0x540 \t? user_path_at+0x51/0x60 \t? __x64_sys_mount+0x212/0x280 \t? srso_return_thunk+0x5/0x5f \t__x64_sys_mount+0x212/0x280 \t? __pfx___x64_sys_mount+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \tdo_syscall_64+0x111/0x680 \tentry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7ffacad55eae \tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 \tRSP: 002b ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46169", "url": "https://ubuntu.com/security/CVE-2026-46169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45991", "url": "https://ubuntu.com/security/CVE-2026-45991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46065", "url": "https://ubuntu.com/security/CVE-2026-46065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46086", "url": "https://ubuntu.com/security/CVE-2026-46086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46003", "url": "https://ubuntu.com/security/CVE-2026-46003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46038", "url": "https://ubuntu.com/security/CVE-2026-46038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46026", "url": "https://ubuntu.com/security/CVE-2026-46026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46091", "url": "https://ubuntu.com/security/CVE-2026-46091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46078", "url": "https://ubuntu.com/security/CVE-2026-46078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46069", "url": "https://ubuntu.com/security/CVE-2026-46069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46021", "url": "https://ubuntu.com/security/CVE-2026-46021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46092", "url": "https://ubuntu.com/security/CVE-2026-46092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: check for PCI upstream bridge existence pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31700", "url": "https://ubuntu.com/security/CVE-2026-31700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31712", "url": "https://ubuntu.com/security/CVE-2026-31712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require minimum ACE size in smb_check_perm_dacl() Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31708", "url": "https://ubuntu.com/security/CVE-2026-31708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43350", "url": "https://ubuntu.com/security/CVE-2026-43350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: require a full NFS mode SID before reading mode bits parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31711", "url": "https://ubuntu.com/security/CVE-2026-31711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix active_num_conn leak on transport allocation failure Commit 77ffbcac4e56 (\"smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with \"Limit the maximum number of connections\". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31715", "url": "https://ubuntu.com/security/CVE-2026-31715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() The xfstests case \"generic/107\" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43492", "url": "https://ubuntu.com/security/CVE-2026-43492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting \"lzeros\" from the unsigned \"nbytes\". For this to happen, the scatterlist \"sgl\" needs to occupy more bytes than the \"nbytes\" parameter and the first \"nbytes + 1\" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than \"nbytes\", subtract the number of zeroes from \"nbytes\" and cause the underflow. When commit 2d4d1eea540b (\"lib/mpi: Add mpi sgl helpers\") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to \"nbytes\". However since commit 63ba4d67594a (\"KEYS: asymmetric: Use new crypto interface without scatterlists\"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger \"out_len\" than \"in_len\" and filling the \"in\" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the \"src\" and \"dst\" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "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.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-52933", "url": "https://ubuntu.com/security/CVE-2026-52933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix signed comparison in io_poll_get_ownership() io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2025-22026", "url": "https://ubuntu.com/security/CVE-2025-22026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2023-54125", "url": "https://ubuntu.com/security/CVE-2023-54125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Return error for inconsistent extended attributes ntfs_read_ea is called when we want to read extended attributes. There are some sanity checks for the validity of the EAs. However, it fails to return a proper error code for the inconsistent attributes, which might lead to unpredicted memory accesses after return. [ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0 [ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199 [ 138.931132] [ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4 [ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 138.947327] Call Trace: [ 138.949557] [ 138.951539] dump_stack_lvl+0x4d/0x67 [ 138.956834] print_report+0x16f/0x4a6 [ 138.960798] ? ntfs_set_ea+0x453/0xbf0 [ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200 [ 138.969793] ? ntfs_set_ea+0x453/0xbf0 [ 138.973523] kasan_report+0xb8/0x140 [ 138.976740] ? ntfs_set_ea+0x453/0xbf0 [ 138.980578] __asan_store4+0x76/0xa0 [ 138.984669] ntfs_set_ea+0x453/0xbf0 [ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10 [ 138.993390] ? kernel_text_address+0xd3/0xe0 [ 138.998270] ? __kernel_text_address+0x16/0x50 [ 139.002121] ? unwind_get_return_address+0x3e/0x60 [ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 139.010177] ? arch_stack_walk+0xa2/0x100 [ 139.013657] ? filter_irq_stacks+0x27/0x80 [ 139.017018] ntfs_setxattr+0x405/0x440 [ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10 [ 139.026569] ? kvmalloc_node+0x2d/0x120 [ 139.030329] ? kasan_save_stack+0x41/0x60 [ 139.033883] ? kasan_save_stack+0x2a/0x60 [ 139.037338] ? kasan_set_track+0x29/0x40 [ 139.040163] ? kasan_save_alloc_info+0x1f/0x30 [ 139.043588] ? __kasan_kmalloc+0x8b/0xa0 [ 139.047255] ? __kmalloc_node+0x68/0x150 [ 139.051264] ? kvmalloc_node+0x2d/0x120 [ 139.055301] ? vmemdup_user+0x2b/0xa0 [ 139.058584] __vfs_setxattr+0x121/0x170 [ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10 [ 139.066282] __vfs_setxattr_noperm+0x97/0x300 [ 139.070061] __vfs_setxattr_locked+0x145/0x170 [ 139.073580] vfs_setxattr+0x137/0x2a0 [ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10 [ 139.080223] ? __kasan_check_write+0x18/0x20 [ 139.084234] do_setxattr+0xce/0x150 [ 139.087768] setxattr+0x126/0x140 [ 139.091250] ? __pfx_setxattr+0x10/0x10 [ 139.094948] ? __virt_addr_valid+0xcb/0x140 [ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330 [ 139.102688] ? debug_smp_processor_id+0x1b/0x30 [ 139.105985] ? kasan_quarantine_put+0x5b/0x190 [ 139.109980] ? putname+0x84/0xa0 [ 139.113886] ? __kasan_slab_free+0x11e/0x1b0 [ 139.117961] ? putname+0x84/0xa0 [ 139.121316] ? preempt_count_sub+0x1c/0xd0 [ 139.124427] ? __mnt_want_write+0xae/0x100 [ 139.127836] ? mnt_want_write+0x8f/0x150 [ 139.130954] path_setxattr+0x164/0x180 [ 139.133998] ? __pfx_path_setxattr+0x10/0x10 [ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10 [ 139.141299] ? debug_smp_processor_id+0x1b/0x30 [ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80 [ 139.150796] __x64_sys_setxattr+0x71/0x90 [ 139.155407] do_syscall_64+0x3f/0x90 [ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 139.163843] RIP: 0033:0x7f108cae4469 [ 139.166481] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc [ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469 [ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6 [ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618 [ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0 [ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15 ---truncated---", "cve_priority": "high", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2026-31449", "url": "https://ubuntu.com/security/CVE-2026-31449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: validate p_idx bounds in ext4_ext_correct_indexes ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level. If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read. Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "high", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43064", "url": "https://ubuntu.com/security/CVE-2026-43064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix not releasing workqueue on .release() The workqueue associated with an DSA/IAA device is not released when the object is freed.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165588, 2166457, 1786013, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2163508, 2164699, 1961566, 1956562, 2164516, 2137199, 2165170, 2165170, 2165166, 2165125, 2165125, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2164800 ], "changes": [ { "cves": [ { "cve": "CVE-2026-64582", "url": "https://ubuntu.com/security/CVE-2026-64582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix a use-after-free problem in rxe_mmap rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1: list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */ ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */ [...] rxe_vma_open(vma); /* kref_get, ref → 2 */ remap_vmalloc_range_partial() walks PTEs without any lock. A concurrent DESTROY_CQ ioctl on another CPU calls: kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */ vfree(ip->obj) /* clears vmalloc PTEs mid-walk */ kfree(ip) /* frees rxe_mmap_info */ This yields: 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF. It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get). The call trace are as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:validate_page_before_insert+0x32/0x300 Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5 RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00 R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20 FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0 Call Trace: insert_page+0x8f/0x190 ? __pfx_insert_page+0x10/0x10 ? kasan_save_alloc_info+0x38/0x60 vm_insert_page+0x2e7/0x400 remap_vmalloc_range_partial+0x212/0x3e0 remap_vmalloc_range+0x6e/0xb0 ? __kasan_check_write+0x14/0x30 rxe_mmap+0x2e9/0x5d0 ib_uverbs_mmap+0x1ad/0x2c0 __mmap_region+0x12c2/0x2ad0 ? __pfx___mmap_region+0x10/0x10 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_prev_slot+0x360/0x39c0 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_next_slot+0x1e5b/0x2f40 ? __sanitizer_cov_trace_cmp8+0x18/0x30 ? unmapped_area_topdown+0x4dd/0x610 ? kfree+0x1b1/0x440 ? free_cpumask_var+0x16/0x30 ? __kasan_slab_free+0x7d/0xa0 ? __sanitizer_cov_trace_cmp8+0x18/0x30 mmap_region+0x2e6/0x3c0 do_mmap+0xa3e/0x12a0 ? __pfx_do_mmap+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? down_write_killable+0xba/0x160 ? __pfx_down_write_killable+0x10/0x10 ? __sanitizer_cov_trace_cmp4+0x16/0x30 vm_mmap_pgoff+0x2d4/0x4a0 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x1bf/0x270 ksys_mmap_pgoff+0x40c/0x690 ? __sanitizer_cov_trace_const_cmp4+0x16/0x30 ? __pfx_ksys_mmap_pgoff+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? _raw_spin_trylock+0xbb/0x130 ? __pfx__raw_spin_trylock+0x10/0x10 __x64_sys_mmap+0x135/0x1e0 x64_sys_c ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-05 12:18:00 UTC" }, { "cve": "CVE-2026-74468", "url": "https://ubuntu.com/security/CVE-2026-74468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 (\"gpio: sch: use raw_spinlock_t in the irq startup path\") and commit 90f0109019e6 (\"gpio: eic-sprd: use raw_spinlock_t in the irq startup path\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74482", "url": "https://ubuntu.com/security/CVE-2026-74482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74443", "url": "https://ubuntu.com/security/CVE-2026-74443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at \t(unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74444", "url": "https://ubuntu.com/security/CVE-2026-74444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes \tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74453", "url": "https://ubuntu.com/security/CVE-2026-74453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the \"Auto-initialise Tile State Data Array\" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74455", "url": "https://ubuntu.com/security/CVE-2026-74455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: validate uCAN receive record lengths pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74456", "url": "https://ubuntu.com/security/CVE-2026-74456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 (\"net: usb: lan78xx: Fix double free issue with interrupt buffer allocation\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74457", "url": "https://ubuntu.com/security/CVE-2026-74457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74458", "url": "https://ubuntu.com/security/CVE-2026-74458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74459", "url": "https://ubuntu.com/security/CVE-2026-74459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74460", "url": "https://ubuntu.com/security/CVE-2026-74460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74461", "url": "https://ubuntu.com/security/CVE-2026-74461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74463", "url": "https://ubuntu.com/security/CVE-2026-74463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74464", "url": "https://ubuntu.com/security/CVE-2026-74464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74465", "url": "https://ubuntu.com/security/CVE-2026-74465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the \"hash\" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68451", "url": "https://ubuntu.com/security/CVE-2026-68451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA ECC private key requests cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "high", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68452", "url": "https://ubuntu.com/security/CVE-2026-68452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-74467", "url": "https://ubuntu.com/security/CVE-2026-74467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Check CAP_NET_ADMIN for private ioctls Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74469", "url": "https://ubuntu.com/security/CVE-2026-74469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74471", "url": "https://ubuntu.com/security/CVE-2026-74471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Check return value of __register_event() in trace_module_add_events() trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74473", "url": "https://ubuntu.com/security/CVE-2026-74473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74475", "url": "https://ubuntu.com/security/CVE-2026-74475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74478", "url": "https://ubuntu.com/security/CVE-2026-74478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: vector: fix use-after-free in vector_mmsg_rx() When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: \tif (header_check < 0) { \t\tdev_kfree_skb_irq(skb); \t\tvp->estats.rx_encaps_errors++; \t\tcontinue; \t} The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: \t(*skbuff_vector) = NULL; \tmmsg_vector++; \tskbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74480", "url": "https://ubuntu.com/security/CVE-2026-74480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74481", "url": "https://ubuntu.com/security/CVE-2026-74481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74485", "url": "https://ubuntu.com/security/CVE-2026-74485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: reject a flag character as the field delimiter The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: \tmemset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering \tPaPEPPxPPiP with 'P' as the delimiter (name \"a\", type extension, magic \"x\", interpreter \"i\", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74488", "url": "https://ubuntu.com/security/CVE-2026-74488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: \trx_skb = __skb_dequeue(&list); \trx_hdr = (struct rx_packet_hdr *)rx_skb->data; \tif (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && \t ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { \t\tmwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, \t\t\t\t\t\t skb->len); \t} The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with \tif (!reuse_skb) \t\tdev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes \ties_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, \tfor (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { \t\tu8 ie_len = pos[1]; \t\tif (pos + 2 + ie_len > end) \t\t\tbreak; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74490", "url": "https://ubuntu.com/security/CVE-2026-74490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74492", "url": "https://ubuntu.com/security/CVE-2026-74492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: do not update comments from kernel-side hash adds mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74493", "url": "https://ubuntu.com/security/CVE-2026-74493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket use-after-free during link group termination __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74495", "url": "https://ubuntu.com/security/CVE-2026-74495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74497", "url": "https://ubuntu.com/security/CVE-2026-74497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74498", "url": "https://ubuntu.com/security/CVE-2026-74498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74499", "url": "https://ubuntu.com/security/CVE-2026-74499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() snd_usbmidi_akai_output() computes its fill-loop bound \tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74505", "url": "https://ubuntu.com/security/CVE-2026-74505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74507", "url": "https://ubuntu.com/security/CVE-2026-74507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74508", "url": "https://ubuntu.com/security/CVE-2026-74508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74512", "url": "https://ubuntu.com/security/CVE-2026-74512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74518", "url": "https://ubuntu.com/security/CVE-2026-74518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocate_file_region_entries() allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74519", "url": "https://ubuntu.com/security/CVE-2026-74519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-74523", "url": "https://ubuntu.com/security/CVE-2026-74523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74525", "url": "https://ubuntu.com/security/CVE-2026-74525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: free TX rings on RX allocation failure When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74540", "url": "https://ubuntu.com/security/CVE-2026-74540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74546", "url": "https://ubuntu.com/security/CVE-2026-74546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74547", "url": "https://ubuntu.com/security/CVE-2026-74547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74548", "url": "https://ubuntu.com/security/CVE-2026-74548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix UAF of txrx_stats in nv_remove nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74549", "url": "https://ubuntu.com/security/CVE-2026-74549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74556", "url": "https://ubuntu.com/security/CVE-2026-74556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74557", "url": "https://ubuntu.com/security/CVE-2026-74557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: \tsenselen = get_unaligned_be16(data); \tif (datalen < senselen) \t\tgoto invalid_datalen; \tmemcpy(sc->sense_buffer, data + 2, \t min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74563", "url": "https://ubuntu.com/security/CVE-2026-74563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74579", "url": "https://ubuntu.com/security/CVE-2026-74579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes.", "cve_priority": "medium", "cve_public_date": "2026-08-17 06:19:00 UTC" }, { "cve": "CVE-2026-74564", "url": "https://ubuntu.com/security/CVE-2026-74564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74566", "url": "https://ubuntu.com/security/CVE-2026-74566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: make keyring key-chunk byte order agree with keyring_diff_objects() keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74567", "url": "https://ubuntu.com/security/CVE-2026-74567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74569", "url": "https://ubuntu.com/security/CVE-2026-74569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and \"datalen = datalen + diff - msglen\" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-43491", "url": "https://ubuntu.com/security/CVE-2026-43491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-74577", "url": "https://ubuntu.com/security/CVE-2026-74577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: \tr = nlmsg_data(nlh); \tr->rtm_family\t = AF_MPLS; \tr->rtm_dst_len\t= 20; \tr->rtm_src_len\t= 0; \tr->rtm_table\t= RT_TABLE_MAIN; \tr->rtm_type\t= RTN_UNICAST; \tr->rtm_scope\t= RT_SCOPE_UNIVERSE; \tr->rtm_protocol = rt->rt_protocol; \tr->rtm_flags\t= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64543", "url": "https://ubuntu.com/security/CVE-2026-64543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix use-after-free of the discoverer in tipc_disc_rcv() bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(), but tipc_disc_rcv() still dereferences b->disc in RX softirq under rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv). L2 bearers are safe thanks to the synchronize_net() in tipc_disable_l2_media(), but the UDP bearer defers that call to the cleanup_bearer() workqueue, so the discoverer is freed with no grace period: BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149) Read of size 8 at addr ffff88802348b728 by task poc_tipc/184 tipc_disc_rcv (net/tipc/discover.c:149) tipc_rcv (net/tipc/node.c:2126) tipc_udp_recv (net/tipc/udp_media.c:391) udp_rcv (net/ipv4/udp.c:2643) ip_local_deliver_finish (net/ipv4/ip_input.c:241) Freed by task 181: kfree (mm/slub.c:6565) bearer_disable (net/tipc/bearer.c:418) tipc_nl_bearer_disable (net/tipc/bearer.c:1001) The bearer is freed with kfree_rcu(); free the discoverer the same way. Add an rcu_head to struct tipc_discoverer and free it and its skb from an RCU callback. Because the RCU callback (tipc_disc_free_rcu) lives in module text, a call_rcu() that is still pending when the tipc module is unloaded would invoke a freed function. Add an rcu_barrier() to tipc_exit() after the bearer subsystem has been torn down, so all pending discoverer callbacks have run before the module text goes away. Reachable from an unprivileged user namespace: the TIPCv2 genl family is netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC and CONFIG_TIPC_MEDIA_UDP.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72123", "url": "https://ubuntu.com/security/CVE-2026-72123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 (\"can: bcm: use call_rcu() instead of costly synchronize_rcu()\") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a \"scheduling while atomic\" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72019", "url": "https://ubuntu.com/security/CVE-2026-72019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d (\"macvlan: do not assume mac_header is set in macvlan_broadcast()\") for exactly this purpose.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-52977", "url": "https://ubuntu.com/security/CVE-2026-52977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-72282", "url": "https://ubuntu.com/security/CVE-2026-72282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72068", "url": "https://ubuntu.com/security/CVE-2026-72068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64301", "url": "https://ubuntu.com/security/CVE-2026-64301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error path where process_scmi_regulator_of_node() fails, the function returns without calling of_node_put() on the child node, leaking the reference. Add of_node_put(np) on the error path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64304", "url": "https://ubuntu.com/security/CVE-2026-64304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - validate RSA CRT component lengths The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64593", "url": "https://ubuntu.com/security/CVE-2026-64593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not trim a device which is not writeable [BUG] There is a bug report that btrfs/242 can randomly fail with the following NULL pointer dereference: run fstests btrfs/242 at 2026-06-01 10:25:08 BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609) BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874 BTRFS info (device sdc): using crc32c checksum algorithm BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS info (device sdc): allowing degraded mounts BTRFS info (device sdc): turning on async discard BTRFS info (device sdc): enabling free space tree Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000 CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_trim_fs+0x34c/0xa00 [btrfs] lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs] Call trace: btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P) btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] __arm64_sys_ioctl+0xac/0x108 invoke_syscall.constprop.0+0x5c/0xd0 el0_svc_common.constprop.0+0x40/0xf0 do_el0_svc+0x24/0x40 el0_svc+0x40/0x1d0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00) ---[ end trace 0000000000000000 ]--- Also the reporter is very kind to test the following ASSERT() added to btrfs_trim_free_extents_throttle(): \tASSERT(device->bdev, \t \"devid=%llu path=%s dev_state=0x%lx\\n\", \t device->devid, btrfs_dev_name(device), device->dev_state); And it shows the following output: assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82) Which means the device->bdev is NULL, and the dev_state is BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without BTRFS_DEV_STATE_WRITEABLE flag set. [CAUSE] The pc points to the following call chain: btrfs_trim_fs() |- btrfs_trim_free_extents() |- btrfs_trim_free_extents_throttle() |- bdev_max_discard_sectors(device->bdev) So the NULL pointer dereference is caused by device->bdev being NULL. This looks impossible by a quick glance, as just before calling btrfs_trim_free_extents_throttle(), we have skipped any device that has BTRFS_DEV_STATE_MISSING flag set. However in this particular case, there is a window where the missing device is later re-scanned, causing btrfs to remove the BTRFS_DEV_STATE_MISSING flag: btrfs_control_ioctl() |- btrfs_scan_one_device() |- device_list_add() |- rcu_assign_pointer(device->name, name); | This updates the missing device's path to the new good path. | |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state) This removes the BTRFS_DEV_STATE_MISSING flag. This allows the missing device to re-appear and clear the BTRFS_DEV_STATE_MISSING flag. However the device still does not have the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated. The bdev pointer remains NULL, triggering the crash later. [FIX] This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and device->bdev pointer, and shows a gap in btrfs's re-appearing-device handling. The proper handling of re-appearing device will need quite some extra work, which is out of the context of this small ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64594", "url": "https://ubuntu.com/security/CVE-2026-64594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: initialize reset_work at allocation time ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on ffs->reset_work when a functionfs instance is unmounted: \tffs_data_reset(ffs); \tcancel_work_sync(&ffs->reset_work); However ffs->reset_work is only ever initialized via INIT_WORK() in ffs_func_set_alt() and ffs_func_disable(), and only on the FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed() when the instance is mounted with the \"no_disconnect\" option, so for the common case (no \"no_disconnect\", or mounted and unmounted without ever being deactivated) reset_work is never initialized. ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch it either, so reset_work.func is left NULL. cancel_work_sync() on such a work then trips the WARN_ON(!work->func) guard in __flush_work(): WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flush_work cancel_work_sync ffs_fs_kill_sb [usb_f_fs] deactivate_locked_super deactivate_super cleanup_mnt __cleanup_mnt task_work_run exit_to_user_mode_loop el0_svc On older kernels cancel_work_sync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization. Initialize reset_work once in ffs_data_new() so it is always valid for the lifetime of the ffs_data, and drop the now-redundant INIT_WORK() calls from the two deactivation paths.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68456", "url": "https://ubuntu.com/security/CVE-2026-68456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect() ueagle-atm uses the asynchronous request_firmware_nowait() in .probe(), but does not wait for its completion, not even in .disconnect(); so, if the device is unplugged meanwhile, its teardown runs concurrently with that. Even though this inconsistency is worth addressing on its own, it has also triggered several bug reports in syzbot over the years (some auto-closed) where the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER) creates a firmware subdirectory in the device directory during its removal, which might hit unexpected conditions in kernfs, apparently, depending at which point the add and remove operations raced. (See links.) The pattern is: usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2 usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw Call trace: ... kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs _request_firmware request_firmware_work_func ... (Some variations are observed, after fw_load_sysfs_fallback(), e.g., [1].) While the kernfs side is being looked at, the ueagle-atm side can be fixed by waiting for the pre-firmware load in the .disconnect() handler. This change has a similar approach to previous work by Andrey Tsygunka [2] (wait_for_completion() in .disconnect()), but it is relatively different in design/implementation; using the Originally-by tag for credit assignment. This has been tested with: - synthetic reproducer to check the error path; - USB gadget (virtual device) to check the firmware upload path; - QEMU device emulator to check the device ID re-enumeration path; (The latter two were written by Claude; no other code/text in this commit.) Links (year first reported): 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd4 2024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84d86f0d71394829df6fc53daf6642c045983881 2021 https://syzbot.org/bug?id=3302dc1c0e2b9c94f2e8edb404eabc9267bc6f90 [1] https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 [2] https://lore.kernel.org/lkml/20250410093146.3776801-2-aitsygunka@yandex.ru/", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-64329", "url": "https://ubuntu.com/security/CVE-2026-64329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled. The probe error path already orders free_irq() before ucsi_destroy(). This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64352", "url": "https://ubuntu.com/security/CVE-2026-64352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to \"c || rcu_read_lock_held()\", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64355", "url": "https://ubuntu.com/security/CVE-2026-64355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject fragmented frames in devmap Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64361", "url": "https://ubuntu.com/security/CVE-2026-64361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length check_and_correct_requested_length() compares (off + len) against node_size using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfs_brec_remove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail. For example, with off=14 and len=0xFFFFFFF2 (underflowed from data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6, which is less than a typical node_size of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer. Fix this by widening the addition to u64 before comparing against node_size. This prevents the u32 wrap while keeping the logic straightforward.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64363", "url": "https://ubuntu.com/security/CVE-2026-64363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: appleir: fix UAF on pending key_up_timer in remove() appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 (\"HID: appletb-kbd: fix UAF in inactivity-timer cleanup path\") and has been present since the driver was introduced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64371", "url": "https://ubuntu.com/security/CVE-2026-64371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (part 1) Fix the easy cases where procfs currently calls ptrace_may_access() without exec_update_lock protection, where the fix is to simply add the extra lock or use mm_access(): - do_task_stat(): grab exec_update_lock - proc_pid_wchan(): grab exec_update_lock - proc_map_files_lookup(): use mm_access() instead of get_task_mm() - proc_map_files_readdir(): use mm_access() instead of get_task_mm() - proc_ns_get_link(): grab exec_update_lock - proc_ns_readlink(): grab exec_update_lock", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64364", "url": "https://ubuntu.com/security/CVE-2026-64364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix out-of-bounds bit access on mt_io_flags mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG. As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs \tfor (i = 0; i < mt->num_slots; i++) \t\tclear_bit(i, &td->mt_io_flags); with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received). The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required. Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two \"mt_io_flags & MT_IO_SLOTS_MASK\" arming checks become bitmap_empty(td->active_slots, td->maxcontacts). Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64375", "url": "https://ubuntu.com/security/CVE-2026-64375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (FD links) proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways. To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link().", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64390", "url": "https://ubuntu.com/security/CVE-2026-64390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: track the connection owning a byte-range lock SMB2_LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llist_lock. With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbd_lock and struct file_lock objects. Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llist_lock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-31610", "url": "https://ubuntu.com/security/CVE-2026-31610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: \tif (conn->use_spnego && conn->mechToken) { \t\tkfree(conn->mechToken); \t\tconn->mechToken = NULL; \t} so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-64380", "url": "https://ubuntu.com/security/CVE-2026-64380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: harden POSIX SID length parsing posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64379", "url": "https://ubuntu.com/security/CVE-2026-64379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: mask server-provided mode to 07777 in modefromsid When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64401", "url": "https://ubuntu.com/security/CVE-2026-64401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: resolve SWN tcon from live registrations cifs_swn_notify() looks up a witness registration by id under cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifs_get_swn_reg() lets multiple tcons for the same net/share name share one registration id. A same-share second mount can keep the cifs_swn_reg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tc_lock or incrementing tc_count through swnreg->tcon only moves the use-after-free earlier. Taking tc_lock while holding cifs_swnreg_idr_mutex also violates the documented CIFS lock order. Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifs_tcp_ses_lock -> tc_lock order. The notification path uses that pinned tcon directly and drops the reference when done. Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifs_swn_unregister() while the registration is still protected by cifs_swnreg_idr_mutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings. This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENT_MOVE ordering for the representative tcon because the old-IP unregister is sent before cifs_swn_register() sends the new-IP register.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64381", "url": "https://ubuntu.com/security/CVE-2026-64381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix next buffer leak in receive_encrypted_standard() receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64206", "url": "https://ubuntu.com/security/CVE-2026-64206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64413", "url": "https://ubuntu.com/security/CVE-2026-64413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: zero chainstack array sashiko reports: looking at ebtables table translation, could a sparse cpu_possible_mask lead to an uninitialized pointer free? If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1]. Not a real-world bug, such allocation isn't expected to fail in the first place.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64428", "url": "https://ubuntu.com/security/CVE-2026-64428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: sch: use raw_spinlock_t in the irq startup path sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64438", "url": "https://ubuntu.com/security/CVE-2026-64438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix VF2PF work teardown race in adf_disable_sriov() The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adf_accel_vf_info). Currently, adf_disable_sriov() destroys per-VF mutexes and frees vf_info without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory. This manifests as a use-after-free when KASAN is enabled: BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] Call Trace: kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vf_info is destroyed. Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64441", "url": "https://ubuntu.com/security/CVE-2026-64441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr() Three IE/attribute parsing functions have missing bounds checks. rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtw_get_sec_ie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain. rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at entry, before verifying that wps_ielen is large enough to contain the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside the attribute loop, get_unaligned_be16() is called on attr_ptr and attr_ptr+2 without checking that 4 bytes remain in the buffer. Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie() and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum IE length requirement, add a wps_ielen < 6 early return in rtw_get_wps_attr(), and add a 4-byte bounds check in its inner loop.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64461", "url": "https://ubuntu.com/security/CVE-2026-64461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64446", "url": "https://ubuntu.com/security/CVE-2026-64446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie() supplicant_ie is a 256-byte array in struct security_priv. The WPA and WPA2 IE copy paths use: memcpy(padapter->securitypriv.supplicant_ie, &pwpa[0], wpa_ielen + 2); where wpa_ielen is the raw IE length field (u8, 0-255). When a local user supplies a connect request via nl80211 with a crafted WPA IE of length 255, wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into the adjacent last_mic_err_time field. rtw_parse_wpa_ie() does not prevent this: its length consistency check compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255 when wpa_ie_len = 257, so the check passes silently. Add explicit bounds checks for both the WPA and WPA2 paths before the memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the supplicant_ie buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64448", "url": "https://ubuntu.com/security/CVE-2026-64448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: restrict implied bcc[0] exemption to responses without data area smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received (\"server can return one byte more due to implied bcc[0]\"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, yet smb2_check_message() still accepts it. The subsequent decoder then reads past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server; both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders are affected: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00 Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81 CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 asn1_ber_decoder+0x16a7/0x1b00 decode_negTokenInit+0x19/0x30 SMB2_negotiate+0x31d9/0x4c90 cifs_negotiate_protocol+0x1f2/0x3f0 cifs_get_smb_ses+0x93f/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 85: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 0 bytes to the right of allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0) which belongs to the cache cifs_small_rq of size 448 BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50 Read of size 329 at addr ffff88800726c678 by task mount.cifs/89 CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x36/0x50 decode_ntlmssp_challenge+0x457/0x680 SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0 SMB2_sess_setup+0x219/0x4f0 cifs_setup_session+0x248/0xaf0 cifs_get_smb_ses+0xf79/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 93: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 120 bytes inside of allocated 448-byte region [ffff88800726c600, ffff88800726c7c0) which belongs to the cache cifs_small_rq of size 448 Restrict the +1 exemption to responses that have no data area, so that it still covers the bcc[0] omission it was meant for. When a data area is present, the +1 discrepancy instead means the reported data length overruns the ---truncated---", "cve_priority": "negligible", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64462", "url": "https://ubuntu.com/security/CVE-2026-64462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64475", "url": "https://ubuntu.com/security/CVE-2026-64475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Release the VGA arbiter client on register_device() failure The re-order in the Fixes commit below displaced vfio_pci_vga_init() as the last failure point of what is now vfio_pci_core_register_device() without introducing an unwind for the VGA arbiter registration. In current kernels this is mostly benign because vfio_pci_set_decode() only uses pci_dev state, but the original failure path could leave a callback with a freed vdev cookie. The stale registration also becomes unsafe again once the callback follows drvdata to the vfio device. Add the required VGA unwind callout.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64488", "url": "https://ubuntu.com/security/CVE-2026-64488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return early if any fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64510", "url": "https://ubuntu.com/security/CVE-2026-64510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64512", "url": "https://ubuntu.com/security/CVE-2026-64512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Suppress UBSAN warning caused by field misuse The definition of reg->access_width changes depending on the reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses access_width to indicate the PCC region, which can result in a UBSAN if the value is greater than 4. For example: UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9 shift exponent 32 is too large for 32-bit type 'int' CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy) Hardware name: To be filled by O.E.M. Call trace: ...(trimming) ubsan_epilogue+0x10/0x48 __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ... (trimming) Lets fix this by validating the region type, as well as whether access_width has a value. Then since we are returning bit_width directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting the size.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68466", "url": "https://ubuntu.com/security/CVE-2026-68466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68467", "url": "https://ubuntu.com/security/CVE-2026-68467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mchp23k256: use SPI match data for chip caps The driver stores chip capacity information in both the OF match table and the SPI id table. Probe currently uses of_device_get_match_data(), so a non-OF SPI modalias match falls back to mchp23k256_caps even when the SPI id table selected a different part. Use spi_get_device_match_data() so SPI id-table driver_data is consumed when OF match data is absent. This keeps the existing default fallback while avoiding the wrong MTD geometry for id-table-only matches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68469", "url": "https://ubuntu.com/security/CVE-2026-68469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix permanently busy scans after multiple roam iterations In order for the firmware to sleep, the driver has to confirm a previously received sleep request. The normal sequence of evets goes like this: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Before sending the sleep-confirm command, the driver must make sure there are no commands either running or waiting to be completed. mwifiex_ret_802_11_associate() unconditionally sets ps_state = PS_STATE_AWAKE when it processes the association command response, outside of the normal powersave management flow. If EVENT_SLEEP arrives while the association command is in flight, ps_state is PRE_SLEEP when the association command response is parsed, and the forced AWAKE overwrites it. The deferred sleep-confirm is never sent. A subsequent scan_start command is correctly acknowledged, but the firmware doesn't generate scan_result events. The scan request never finishes, and additional requests from userspace fail with -EBUSY. After testing on both IW412 and W8997, I could only trigger the bug on the IW412 and observed the firmwares behave differently. On the IW412 the firmware still sends EVENT_SLEEP while the authentication / association process is ongoing. A W8997 under the same conditions seems to suppress power-save for the duration of the association, so PRE_SLEEP never coincided with the association response even after extended periods of testing using the loops described below (>12hours). On the IW412, the delay between commands that triggers an EVENT_SLEEP was empirically determined to be ~20ms. This delay can naturally occur when the driver is outputting debugging information (debug_mask = 0x00000037), in which situation the busy scans issue is repeatable while running \"test 1)\" as described below. If the delay between commands is less than ~20ms, the firmware stays awake and the issue was not reproducible running the same test. The host_mlme=false path also behaves differently. In this case, the entire authentication / association transaction is executed by one command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit EVENT_SLEEP while the command is running. Remove the assignment so the ps_state is only manipulated in the paths that are related to powersave event handling and on the main workqueue for correct sleep confirmation. The following loop tests were performed (with debugging output enabled): 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations. Each test ran in each device for at least 3 hours.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68474", "url": "https://ubuntu.com/security/CVE-2026-68474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access() spufs_mem_mmap_access() computes the local store offset as address - vma->vm_start, but bounds-checks it against vma->vm_end instead of the local store size. On 64-bit, offset is always well below vma->vm_end, so the clamp never fires and len stays unbounded against the LS_SIZE buffer returned by ctx->ops->get_ls(). Reject offsets at or beyond LS_SIZE and clamp len to the remaining space, mirroring the guard already used by spufs_mem_mmap_fault() and spufs_ps_fault().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68475", "url": "https://ubuntu.com/security/CVE-2026-68475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: reset: sunxi: fix memory region leak on ioremap failure In sunxi_reset_init(), when ioremap() fails, the memory region obtained via request_mem_region() is not released, leading to a resource leak. Add an err_mem_region label to properly release the memory region before freeing the data structure.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68478", "url": "https://ubuntu.com/security/CVE-2026-68478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memstick: ms_block: reject a card that reports too many blocks msb_ftl_initialize() computes the zone count from the card block count with no bound: \tmsb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; \t... \tfor (i = 0; i < msb->zone_count; i++) \t\tmsb->free_block_count[i] = MS_BLOCKS_IN_ZONE; msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the init loop past the end too. A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68479", "url": "https://ubuntu.com/security/CVE-2026-68479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: validate firmware patch bounds rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup. The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72004", "url": "https://ubuntu.com/security/CVE-2026-72004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix memory leak in ieee80211_register_hw() If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl. Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72005", "url": "https://ubuntu.com/security/CVE-2026-72005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: avoid full teardown before work setup in probe rt2x00lib_probe_dev() uses the full rt2x00lib_remove_dev() teardown for all probe failures. However, drv_data allocation and workqueue allocation can fail before intf_work, autowakeup_work and sleep_work have been initialized. Do not enter the full remove path until the probe has reached the point where those work items are set up. Return directly for drv_data allocation failure, and use a small early cleanup path for workqueue allocation failure. This issue was found by our static analysis tool and then confirmed by manual review of rt2x00lib_probe_dev() and rt2x00lib_remove_dev(). The early probe exits should not call a common teardown path that assumes the later work setup has already completed. A QEMU PoC forced alloc_ordered_workqueue() to fail before the work initializers are reached. The resulting fail path entered rt2x00lib_remove_dev(), and DEBUG_OBJECTS reported invalid work drains with rt2x00lib_probe_dev() and rt2x00lib_remove_dev() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72010", "url": "https://ubuntu.com/security/CVE-2026-72010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72013", "url": "https://ubuntu.com/security/CVE-2026-72013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent NULL pointer dereference in machine_kexec_prepare() A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72021", "url": "https://ubuntu.com/security/CVE-2026-72021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in SCTP state lookup set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header. This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed. Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72022", "url": "https://ubuntu.com/security/CVE-2026-72022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: llc: fix SAP refcount leak in llc_ui_autobind() llc_ui_autobind() opens a SAP after choosing a dynamic LSAP. llc_sap_open() returns a reference owned by the caller, and llc_sap_add_socket() takes a second reference for the socket's membership in the SAP hash tables. llc_ui_bind() drops the caller's reference after adding the socket, but llc_ui_autobind() keeps it. When the socket is closed, llc_sap_remove_socket() releases only the socket reference, leaving the SAP on llc_sap_list with sk_count == 0. This is user-visible because repeated autobind and close cycles can consume all dynamic SAP values and make later autobinds fail with -EUSERS. Drop the caller's reference after a successful autobind, matching llc_ui_bind()'s ownership model.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72024", "url": "https://ubuntu.com/security/CVE-2026-72024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: remove interfaces with RCU list deletion Queue wake, stop, and disable paths walk local->interfaces under RCU. The bulk hardware teardown path removes entries with list_del(), so an asynchronous transmit completion can follow a poisoned list node in ieee802154_wake_queue(). Use list_del_rcu() as in the single-interface removal path. The following unregister_netdevice() waits for in-flight RCU readers before freeing the netdevice, so no separate grace-period wait is needed.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72025", "url": "https://ubuntu.com/security/CVE-2026-72025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/monwriter: Reject buffer reuse with different data length When data buffers are reused, e.g. for interval sample records, the first record determines the data length, and the size of the buffer for user copy. Current monwriter code does not check if the data length was changed for subsequent records, which also would never happen for valid user programs. However, a malicious user could change the data length, resulting in out of bounds user copy to the kernel buffer, and memory corruption. By default, the monwriter misc device is created with root-only permissions, so practical impact is typically low. Fix this by checking for changed data length and rejecting such records.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72036", "url": "https://ubuntu.com/security/CVE-2026-72036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked multiq_dequeue() takes a packet from a band's child with a direct ->dequeue() call after multiq_peek() peeked it. When the child is non-work-conserving the peek stashes the skb in the child's gso_skb, so the direct dequeue returns a different skb and orphans the stash, desyncing the child's qlen/backlog. With a qfq child reached through a peeking parent (e.g. tbf) this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_prio already does and as sch_red and sch_sfb were just fixed to do. The helper is a no-op when the child has no stash, so a work-conserving child is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72038", "url": "https://ubuntu.com/security/CVE-2026-72038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: fix BAR resource leak on PF number failure If cn23xx_get_pf_num() fails, the function returns without unmapping either BAR. Unmap both BARs before returning from the error path. Found by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72039", "url": "https://ubuntu.com/security/CVE-2026-72039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72229", "url": "https://ubuntu.com/security/CVE-2026-72229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: clean untagged VLAN on netdev registration failure When an mesh interface is registered, it creates an untagged struct batadv_meshif_vlan on top of it via the NETDEV_REGISTER notifier. But in this process, another receiver of this notification can veto the registration. The netdev registration will be aborted because of this veto. The register_netdevice() call will try to clean up the net_device using unregister_netdevice_queue() - which only uses the .priv_destructor to free private resources. In this situation, .dellink will not be called. The cleanup of the untagged batadv_meshif_vlan must thefore be done in the destructor to avoid a leak of this object.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72232", "url": "https://ubuntu.com/security/CVE-2026-72232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: ensure minimal ethernet header on TX As documented in commit 8bd67ebb50c0 (\"net: bridge: xmit: make sure we have at least eth header len bytes\"), it is possible by for a local user with eBPF TC hook access to attach a tc filter which truncates the packet and redirects to an batadv interface. But the code assumes that at least ETH_HLEN bytes are available and thus might read outside of the available buffer. The batadv_interface_tx() must therefore always check itself if enough data is available for the ethernet header and don't rely on min_header_len.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72235", "url": "https://ubuntu.com/security/CVE-2026-72235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: retrieve ethhdr after potential skb realloc on RX pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72047", "url": "https://ubuntu.com/security/CVE-2026-72047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72048", "url": "https://ubuntu.com/security/CVE-2026-72048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix cas_ctl leak on spi_async failure ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72049", "url": "https://ubuntu.com/security/CVE-2026-72049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: admin-gate legacy LLSEC dump operations In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM. Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the \"802.15.4 MAC\" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames. Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family. Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry \"can be retrieved by unprivileged users\" annotations).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72052", "url": "https://ubuntu.com/security/CVE-2026-72052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72054", "url": "https://ubuntu.com/security/CVE-2026-72054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72055", "url": "https://ubuntu.com/security/CVE-2026-72055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink vti6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72056", "url": "https://ubuntu.com/security/CVE-2026-72056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ena: clean up XDP TX queues when regular TX setup fails create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72061", "url": "https://ubuntu.com/security/CVE-2026-72061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sit: require CAP_NET_ADMIN in the device netns for changelink ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72066", "url": "https://ubuntu.com/security/CVE-2026-72066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Bound hotplug states sysfs output states_show() adds CPU hotplug state names into a single sysfs buffer using sprintf(). With enough registered states, this can write past the end of the PAGE_SIZE buffer. Use sysfs_emit_at() so output is bounded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72067", "url": "https://ubuntu.com/security/CVE-2026-72067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Preserve per instance callback errors cpuhp_invoke_callback() unwinds earlier callbacks for the same hotplug state when one instance fails. The rollback path currently reuses ret, so a successful rollback can hide the original error and make the failed transition look successful. Keep the rollback result separate from the original error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72074", "url": "https://ubuntu.com/security/CVE-2026-72074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix type confusion in CDC union descriptor parsing The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72076", "url": "https://ubuntu.com/security/CVE-2026-72076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72078", "url": "https://ubuntu.com/security/CVE-2026-72078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - validate control endpoint type The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72079", "url": "https://ubuntu.com/security/CVE-2026-72079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix use-after-free and double-free in disconnect ims_pcu_disconnect() only intended to perform cleanup when the primary (control) interface is unbound. However, it currently relies on the interface class to distinguish between control and data interfaces. A malicious device could present a data interface with the same class as the control interface, leading to premature cleanup and potential use-after-free or double-free. Switch to verifying that the interface being disconnected is indeed the control interface.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72081", "url": "https://ubuntu.com/security/CVE-2026-72081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix I/O leak on unsupported additional CDB efct_dispatch_fcp_cmd() allocates an efct_io before dispatching an unsolicited FCP command. If the command has an unsupported additional CDB, the function returns -EIO before handing the IO to the SCSI layer. Free the allocated IO before returning from this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72082", "url": "https://ubuntu.com/security/CVE-2026-72082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix refcount leak in efct_hw_io_abort() When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object. Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery. Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72086", "url": "https://ubuntu.com/security/CVE-2026-72086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free the command tag on the TMR submit-failure path scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag. Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails. transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req. Use the same helper, which returns just the tag, on this path too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72088", "url": "https://ubuntu.com/security/CVE-2026-72088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72102", "url": "https://ubuntu.com/security/CVE-2026-72102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm_early_create: fix freeing used table on dm_resume failure If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72105", "url": "https://ubuntu.com/security/CVE-2026-72105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-log: fix a bitset_size overflow on 32bit machines Commit c20e36b7631d (\"dm log: fix out-of-bounds write due to region_count overflow\") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72107", "url": "https://ubuntu.com/security/CVE-2026-72107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix out-of-bounds memory access for non-zero start sector dm-era tracks writes in target-relative blocks, but era_map() calculates the writeset block before applying the target offset. Tables with a non-zero start sector can therefore pass an absolute mapped-device block to metadata_current_marked(). If the absolute block is beyond the current writeset size, writeset_marked() tests past the end of the in-core bitset. KASAN reports this as a vmalloc-out-of-bounds access. Apply the target offset before calculating the era block so writeset lookups use the target-relative block number.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72108", "url": "https://ubuntu.com/security/CVE-2026-72108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm thin metadata: fix metadata snapshot consistency on commit failure __reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata. Reproducer 1: __reserve_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 112 linear /dev/sdc 0 112 3984 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency. dmsetup message tpool 0 \"reserve_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0. Reproducer 2: __release_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 128 linear /dev/sdc 0 128 3968 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata. dmsetup message tpool 0 \"reserve_metadata_snap\" dmsetup message tpool 0 \"release_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked. Fix by deferring the held_root update to commit time. Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72109", "url": "https://ubuntu.com/security/CVE-2026-72109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sparx5: unregister blocking notifier on init failure sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72120", "url": "https://ubuntu.com/security/CVE-2026-72120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu list annotations and operations sashiko-bot remarked the missing use of list_add_rcu() in bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure when bcm_proc_show() traverses the bcm_op's under rcu_read_lock(). To cover all initial settings of the bcm_op's the list_add_rcu() calls are moved to the end of the setup code. While at it, also fix the mirroring removal side: bcm_release() called bcm_remove_op() - which frees the op via call_rcu() - on ops that were still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first. Unlink each op with list_del_rcu() before handing it to bcm_remove_op(), matching the existing pattern in bcm_delete_tx_op()/bcm_delete_rx_op().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72122", "url": "https://ubuntu.com/security/CVE-2026-72122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all mutate both fields under that same lock. Because the lockless reads and the locked writes are unordered with respect to each other, a racing bcm_notify() (device unregister) or bcm_connect() (concurrent bind on another thread sharing the socket) can make bcm_sendmsg() observe an inconsistent combination, e.g. a stale bound=1 together with the now-cleared ifindex=0, silently turning a socket bound to a specific CAN interface into one that also matches \"any\" interface. Keep the lockless bo->bound check purely as a fast-path reject, and move the ifindex read (and a bo->bound re-check) into the locked section, where every writer already serializes. This removes the possibility of observing the two fields torn against each other, rather than trying to fix it with more READ_ONCE()/WRITE_ONCE() pairs on two independently updated fields. Annotate the now-purely-lockless bo->bound accesses consistently across all its write sites. Also fix bcm_rx_setup() silently returning success when the target device disappears concurrently instead of reporting -ENODEV, so a broken RX op is no longer left registered as if it had succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72126", "url": "https://ubuntu.com/security/CVE-2026-72126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72133", "url": "https://ubuntu.com/security/CVE-2026-72133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: Fix completion initialization order before devm_request_irq() The driver calls devm_request_irq() before initializing the completion used by the interrupt handler. Because the interrupt may occur immediately after devm_request_irq(), the handler may execute before init_completion(). This may result in calling complete() on an uninitialized completion, causing undefined behavior. This has been observed with KASAN. Fix this by initializing the completion before registering the IRQ.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72135", "url": "https://ubuntu.com/security/CVE-2026-72135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Make the TPM character devices non-seekable The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset(). Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale. Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged. Tested on Linux 6.12 with KASAN and a swtpm TPM2 device: - sequential partial reads returned the complete response - pread() and preadv() with offset 0x1400 returned -ESPIPE - pwrite() and pwritev() with offset zero returned -ESPIPE - the pending response remained intact after the rejected operations - a subsequent normal command/response cycle completed normally - no KASAN report was produced.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72136", "url": "https://ubuntu.com/security/CVE-2026-72136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72138", "url": "https://ubuntu.com/security/CVE-2026-72138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Fix these issues by properly handling all error cases.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72140", "url": "https://ubuntu.com/security/CVE-2026-72140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource() If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72153", "url": "https://ubuntu.com/security/CVE-2026-72153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72159", "url": "https://ubuntu.com/security/CVE-2026-72159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72160", "url": "https://ubuntu.com/security/CVE-2026-72160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series \"ocfs2: harden inode validators against forged metadata\", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72163", "url": "https://ubuntu.com/security/CVE-2026-72163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72164", "url": "https://ubuntu.com/security/CVE-2026-72164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: avoid moving extents to occupied clusters For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group. The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated. When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run. Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72165", "url": "https://ubuntu.com/security/CVE-2026-72165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: fix condition in 'nand_select_target()' 'cs' here must be in range [0:nanddev_ntargets[.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72166", "url": "https://ubuntu.com/security/CVE-2026-72166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: \terr = io_wait_event_killable(req->wq, ...) \t/* SIGKILL wakes the task, returns -ERESTARTSYS */ \tif (err == -ERESTARTSYS && c->status == Connected && \t\ttype == P9_TFLUSH) { \t\tsigpending = 1; \t\tclear_thread_flag(TIF_SIGPENDING); \t\tgoto again; \t} clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72167", "url": "https://ubuntu.com/security/CVE-2026-72167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72171", "url": "https://ubuntu.com/security/CVE-2026-72171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: slram: remove failed entries from the device list register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72181", "url": "https://ubuntu.com/security/CVE-2026-72181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mips: sched: Fix CPUMASK_OFFSTACK memory corruption This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72182", "url": "https://ubuntu.com/security/CVE-2026-72182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: fix refcount leak in is_full_charged() In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72193", "url": "https://ubuntu.com/security/CVE-2026-72193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: cap RESTART_TABLE free-chain walker at rt->used A crafted NTFS3 disk image triggers an in-kernel infinite loop at mount time, hanging the mounting thread and firing the soft-lockup watchdog within ~22s on multi-CPU hosts (panic with kernel.softlockup_panic=1). The bug is reachable from desktop USB auto-mount on distributions where udisks2 routes the NTFS signature to the in-tree ntfs3 driver (Arch family and an increasing fraction of Fedora / openSUSE / RHEL deployments); CAP_SYS_ADMIN-class manual mount elsewhere. check_rstbl()'s second walker iterates the free-entry singly-linked list headed by rt->first_free with no upper bound on iteration count: for (off = ff; off;) { if (off == RESTART_ENTRY_ALLOCATED) return false; off = le32_to_cpu(*(__le32 *)Add2Ptr(rt, off)); if (off > ts - sizeof(__le32)) return false; } The existing guards cover three exits: end-of-list (off == 0), the in-use marker (off == RESTART_ENTRY_ALLOCATED), and out-of-bounds (off > ts - sizeof(__le32)). None of the three prevents an in-bounds cycle. A crafted on-disk RESTART_TABLE whose free chain contains a self-loop or A->B->A cycle whose offsets satisfy: - in range [sizeof(struct RESTART_TABLE), ts - sizeof(__le32)] - (off - sizeof(struct RESTART_TABLE)) % rsize == 0 passes all existing guards and spins the mount-time thread forever. Reproduced in UML by hand-forging a 2 MB NTFS3 image whose journal RESTART_TABLE first_free = 0x18 and whose entry at offset 0x18 stores 0x18 as its next pointer; mount of the forged image with the in-tree ntfs3 driver never returns. Bound the walker by rt->used. Each entry on a legitimate free chain is unique, and the total slot count is ne = le16_to_cpu (rt->used). A traversal that visits more than ne slots is by construction malformed; reject it as a corrupt RESTART_TABLE. After this patch, mount of the forged image returns with -EINVAL and a log_replay failure message, and mkntfs-produced legitimate images mount cleanly (verified in the same UML harness).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64532", "url": "https://ubuntu.com/security/CVE-2026-64532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation} In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is `Add2Ptr(e, le16_to_cpu(e->view.data_off))`, where e->view.data_off comes from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validates view.data_off + dlen against e->size; the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate the entry's offset, but not its internal view fields. The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <= e->size. Apply the same bound at the two memmove sites. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE. This is similar in shape to Pavitra Jha's 2026-05-02 patch \"fs/ntfs3: prevent oob in case UpdateRecordDataRoot\" (<20260502105008.21827-1-jhapavitra98@gmail.com>) which proposes calling ntfs3_bad_de_range(); that helper does not exist in mainline. This patch uses inline checks.", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64533", "url": "https://ubuntu.com/security/CVE-2026-64533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate lcns_follow in log_replay conversion log_replay() converts DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY records when replaying version 0 restart tables. During this conversion, the memmove() length is derived directly from the on-disk lcns_follow field: \tmemmove(&dp->vcn, &dp0->vcn_low, \t\t2 * sizeof(u64) + \t\t\t\tle32_to_cpu(dp->lcns_follow) * sizeof(u64)); check_rstbl() validates restart table structure, but does not constrain per-entry lcns_follow values relative to the entry size. A malformed filesystem image can provide an oversized lcns_follow value, causing the conversion memmove() to access memory beyond the bounds of the allocated restart table buffer. The same field is later used to bound iteration over page_lcns[], so validating lcns_follow during conversion also prevents downstream out-of-bounds access from the same malformed metadata. Compute the maximum valid lcns_follow from the already-validated restart table entry size and reject entries that exceed this bound. Reuse the existing t16/t32 scratch variables already declared in log_replay() to avoid introducing new declarations. [almaz.alexandrovich@paragon-software.com: fixed the conflicts]", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72195", "url": "https://ubuntu.com/security/CVE-2026-72195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment \tattr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72197", "url": "https://ubuntu.com/security/CVE-2026-72197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: \tif (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || \t Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || \t used + esize > le32_to_cpu(hdr->total)) { \t\tgoto dirty_vol; \t} Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72215", "url": "https://ubuntu.com/security/CVE-2026-72215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002. To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant. Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and \"if it ain't broke, don't fix it,\" so just leave them alone.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72218", "url": "https://ubuntu.com/security/CVE-2026-72218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72219", "url": "https://ubuntu.com/security/CVE-2026-72219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file leak when nlm_do_fopen() fails A client can repeatedly drive nlm_do_fopen() failures by presenting file handles that the underlying export rejects. After kzalloc_obj() succeeds in nlm_lookup_file(), the freshly allocated nlm_file is not yet inserted into nlm_files[]. The nlm_do_fopen() failure path jumps to out_unlock, which releases nlm_file_mutex and returns without freeing the allocation, so each failure leaks one nlm_file. Route the failure through out_free so kfree() runs before the function returns.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72223", "url": "https://ubuntu.com/security/CVE-2026-72223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arena sub-allocations on discover_arenas() error path Memory allocated by btt_freelist_init(), btt_rtt_init(), and btt_maplocks_init() is not freed on some discover_arenas() error paths. This leaks memory when arena discovery fails. Add the missing kfree() calls to release the allocations before returning an error. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72224", "url": "https://ubuntu.com/security/CVE-2026-72224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arenas on btt_init() error paths The arenas allocated by discover_arenas() or create_arenas() are not freed on some error paths in btt_init(). This leaks memory when BTT initialization fails. Call free_arenas() from the affected error paths to release the allocations. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72225", "url": "https://ubuntu.com/security/CVE-2026-72225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit() jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check. The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort. Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72228", "url": "https://ubuntu.com/security/CVE-2026-72228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: fix primary_if leak on failed linearization If the skb has a frag_list, it must be linearized before it can be split using skb_split(). But when this step failed, it must not only free the skb but also take care of the reference to the already found primary_if.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72230", "url": "https://ubuntu.com/security/CVE-2026-72230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72231", "url": "https://ubuntu.com/security/CVE-2026-72231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is \"ret == false\". But the actual implementation is checking for \"ret == true\". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72233", "url": "https://ubuntu.com/security/CVE-2026-72233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: reacquire gw address after skb realloc The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72238", "url": "https://ubuntu.com/security/CVE-2026-72238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/boot: Validate console=uart8250 baud rate to fix early boot hang When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72240", "url": "https://ubuntu.com/security/CVE-2026-72240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72241", "url": "https://ubuntu.com/security/CVE-2026-72241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: uleds: Fix potential buffer overread The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72245", "url": "https://ubuntu.com/security/CVE-2026-72245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64554", "url": "https://ubuntu.com/security/CVE-2026-64554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() br_ip6_fragment() gets prevhdr, a pointer into the skb head, from ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb skb_checksum_help() reallocates the head via pskb_expand_head(), leaving prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a use-after-free write. Save prevhdr's offset before skb_checksum_help() and recompute it after, like commit ef0efcd3bd3f (\"ipv6: Fix dangling pointer when ipv6 fragment\"). BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857) Write of size 1 at addr ffff888013ff5016 by task exploit/141 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip6_frag_next (net/ipv6/ip6_output.c:857) br_ip6_fragment (net/ipv6/netfilter.c:212) nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407) nf_hook_slow (net/netfilter/core.c:619) br_forward_finish (net/bridge/br_forward.c:66) __br_forward (net/bridge/br_forward.c:115) maybe_deliver (net/bridge/br_forward.c:191) br_flood (net/bridge/br_forward.c:245) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:442) ... packet_sendmsg (net/packet/af_packet.c:3114) ... do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72247", "url": "https://ubuntu.com/security/CVE-2026-72247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: fix zone comparison in tuple dedup The \"already exists\" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument. Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone. nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents. Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72250", "url": "https://ubuntu.com/security/CVE-2026-72250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header: \tskb->mac_header += sizeof(struct frag_hdr); On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the \"not set\" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom. The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72256", "url": "https://ubuntu.com/security/CVE-2026-72256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_cluster: reject template conntracks in hash match xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72264", "url": "https://ubuntu.com/security/CVE-2026-72264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tridentfb: fix potential memory leak in trident_pci_probe() In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72265", "url": "https://ubuntu.com/security/CVE-2026-72265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: nvidia: fix potential memory leak in nvidiafb_probe() In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72267", "url": "https://ubuntu.com/security/CVE-2026-72267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: carminefb: fix potential memory leak in alloc_carmine_fb() The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72268", "url": "https://ubuntu.com/security/CVE-2026-72268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe() In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72269", "url": "https://ubuntu.com/security/CVE-2026-72269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: fix potential memory leak in uvesafb_probe() Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. Fix this by updating the goto label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72270", "url": "https://ubuntu.com/security/CVE-2026-72270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: s3fb: fix potential memory leak in s3_pci_probe() In s3_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72271", "url": "https://ubuntu.com/security/CVE-2026-72271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: i740fb: fix potential memory leak in i740fb_probe() In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72272", "url": "https://ubuntu.com/security/CVE-2026-72272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: radeon: fix potential memory leak in radeonfb_pci_register() The function radeonfb_pci_register() allocates memory for modelist (by calling radeon_check_modes() which calls fb_add_videomode()). The memory is appended to info->modelist, but is not freed in subsequent error paths. Fix this by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72274", "url": "https://ubuntu.com/security/CVE-2026-72274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: hecubafb: fix potential memory leak in hecubafb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72275", "url": "https://ubuntu.com/security/CVE-2026-72275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72276", "url": "https://ubuntu.com/security/CVE-2026-72276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: metronomefb: fix potential memory leak in metronomefb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72297", "url": "https://ubuntu.com/security/CVE-2026-72297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72298", "url": "https://ubuntu.com/security/CVE-2026-72298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with \tif (!size || len != ALIGN(size, 4) + hdrlen) \t\tgoto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 (\"net: qrtr: fix OOB Read in qrtr_endpoint_post\"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72306", "url": "https://ubuntu.com/security/CVE-2026-72306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72307", "url": "https://ubuntu.com/security/CVE-2026-72307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree. Fix by reinitializing vr inside the error loop with the updated index: \tvr = &mlxsw_sp->router->vrs[i]; so that the loop correctly iterates over all VRs that were actually replaced.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72310", "url": "https://ubuntu.com/security/CVE-2026-72310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds.", "cve_priority": "negligible", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72314", "url": "https://ubuntu.com/security/CVE-2026-72314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72316", "url": "https://ubuntu.com/security/CVE-2026-72316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix NULL pointer dereference in metadata_open() metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72326", "url": "https://ubuntu.com/security/CVE-2026-72326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cake: reject overhead values that underflow length CAKE accepts signed overhead values and stores them in an s16, but the adjusted packet length calculation uses unsigned arithmetic. A negative effective length can therefore wrap to a large value. Such configurations make rate accounting depend on integer wraparound rather than on the packet size userspace intended to model. A static netlink lower bound is not enough because packets reaching CAKE can be smaller than any reasonable manual-overhead allowance. Fold the signed overhead adjustment into the existing datapath MPU clamp so negative adjusted lengths are clamped before link-layer framing adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64549", "url": "https://ubuntu.com/security/CVE-2026-64549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup() bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length: \tbt_dev_info(hdev, \"%s\", (char *)(skb->data + 1)); \thci_set_fw_info(hdev, \"%s\", skb->data + 1); A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file. Print the revision string with a bounded \"%.*s\" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64550", "url": "https://ubuntu.com/security/CVE-2026-64550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: validate MAP frame length before ingress parsing When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes the skb straight to __rmnet_map_ingress_handler(), skipping the length validation that rmnet_map_deaggregate() performs on the aggregated path. The parser then dereferences the MAP header and csum header/trailer based on the on-wire pkt_len without checking skb->len, so a short frame is read out of bounds: BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet Read of size 1 at addr ffff88801118ed00 by task exploit/147 Call Trace: ... rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413) __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089) netif_receive_skb (net/core/dev.c:6460) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2001) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Factor that validation out of rmnet_map_deaggregate() into rmnet_map_validate_packet_len() and run it on the no-aggregation path too. The MAP header is bounds-checked first, since this path can receive a frame shorter than the header.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72347", "url": "https://ubuntu.com/security/CVE-2026-72347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_connmark: reject invalid shift parameters Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmark_tg_shift(). A shift_bits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shift_dir values are also accepted and silently fall back to the left-shift path. Reject invalid revision-2 shift parameters in connmark_tg_check() so malformed rules fail at installation time, before they can reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72349", "url": "https://ubuntu.com/security/CVE-2026-72349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt() On links faster than ~34 Gbps, where byte rate may exceed 2^32-1 (~ 4.3 GBps), the comparison result becomes incorrect because the truncated value no longer reflects the actual estimator rate. Fix by changing the local variables to u64.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72350", "url": "https://ubuntu.com/security/CVE-2026-72350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_u32: reject invalid shift counts u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation. Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64547", "url": "https://ubuntu.com/security/CVE-2026-64547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: net1080: validate packet_len before pad-byte access in rx_fixup For an even packet_len, net1080_rx_fixup() reads the pad byte at skb->data[packet_len] before the skb->len != packet_len check further down, and packet_len is only bounded against NC_MAX_PACKET. A malicious NetChip 1080 device can send a short frame advertising a large even packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the skb: BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14 ... net1080_rx_fixup (drivers/net/usb/net1080.c:384) usbnet_bh (drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3708) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) ... Reject the frame when packet_len >= skb->len before reading.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72371", "url": "https://ubuntu.com/security/CVE-2026-72371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the volume AFS_VOLUME_RM_TREE is set on Fix afs_insert_volume_into_cell() to set AFS_VOLUME_RM_TREE on the volume replaced, not the new volume, as it's now removed from the cell's volume tree. This will cause the old volume to be removed from the tree twice and the new volume never to be removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72374", "url": "https://ubuntu.com/security/CVE-2026-72374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix callback service message parsers to pass through -EAGAIN The AFS filesystem client uses an rxrpc server to listen for callback notifications. Each callback call type handler has a delivery function that parses the incoming request stream, and this should return -EAGAIN the last packet hasn't yet been seen, but all currently queued received data is consumed. afs_extract_data() does this, but the -EAGAIN return is switched to 0 inadvertantly Fix callback service message parsers to pass through -EAGAIN", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72378", "url": "https://ubuntu.com/security/CVE-2026-72378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix error code in afs_extract_vl_addrs() The error codes on these paths are only set on the first iteration through the loop. Set the correct error code on every iteration.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72389", "url": "https://ubuntu.com/security/CVE-2026-72389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: stp: Fix a potential use-after-free when deleting a bridge The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them. This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted. Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted. [1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64540", "url": "https://ubuntu.com/security/CVE-2026-64540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup() genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received. A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes. \tskb_put_data(gl_skb, packet->packet_data, size); then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up. BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72392", "url": "https://ubuntu.com/security/CVE-2026-72392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72396", "url": "https://ubuntu.com/security/CVE-2026-72396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: adm1275: Prevent reading uninitialized stack While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret < 0) { ... } for (mid = adm1275_id; mid->name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like \"adm12\", checking it against \"adm1275\" up to the length of \"adm1275\" will continue reading into uninitialized stack bounds. Prevent reading uninitialized memory by zeroing the stack array.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72400", "url": "https://ubuntu.com/security/CVE-2026-72400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: validate SRH length before reading fixed fields seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields. The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer. Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72406", "url": "https://ubuntu.com/security/CVE-2026-72406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sungem: fix probe error cleanup gem_init_one() calls gem_remove_one() when register_netdev() fails. gem_remove_one() unregisters and frees resources owned by the net_device, including the DMA block, MMIO mapping, PCI regions, and the net_device itself. gem_init_one() then falls through to its own cleanup labels and frees the same resources again. Keep the register_netdev() error path in gem_init_one(): clear drvdata so PM/remove paths do not see a half-registered device, remove the NAPI instance added during probe, and let the existing cleanup labels release the resources once. The issue was found by a local static-analysis checker for probe error paths. The reported path was manually inspected before sending this fix. Compile-tested with CONFIG_SUNGEM=y. Runtime testing was not performed because no sungem hardware is available.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72409", "url": "https://ubuntu.com/security/CVE-2026-72409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvneta: re-enable percpu interrupt on resume On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules NAPI poll, which calls enable_percpu_irq() on completion to unmask. If suspend occurs while NAPI poll is pending (between disable_percpu_irq in the ISR and enable_percpu_irq in poll completion), the interrupt is never re-enabled: 1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule() => MPIC masked, percpu_enabled cpumask bit cleared 2. NAPI poll does not complete before suspend proceeds (on PREEMPT_RT this is highly likely since softirqs run in ksoftirqd which gets frozen; on non-RT it can happen when softirq processing is deferred to ksoftirqd) 3. mvneta_stop_dev => napi_disable(): cancels the pending poll without executing the completion path 4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC (already masked, but records IRQS_SUSPENDED) 5. Resume: mpic_resume checks irq_percpu_is_enabled() => false (bit was cleared in step 1) => skips unmask 6. mvneta_start_dev only restores device-level INTR_NEW_MASK, does not touch the MPIC per-CPU mask Result: MPIC per-CPU interrupt stays masked permanently. The NIC generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never receives them, causing complete loss of network connectivity. Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path to unconditionally unmask the MPIC per-CPU interrupt regardless of pre-suspend state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72414", "url": "https://ubuntu.com/security/CVE-2026-72414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: round up PTP perout pin duration pin_duration is converted from the user-provided period to SJA1105 clock ticks and is later passed as the cycle_time argument to future_base_time(). Very small period values may become zero after the conversion, which can lead to a division by zero in future_base_time(). Round zero pin_duration up to 1 tick so that the smallest unsupported periods use the minimum non-zero hardware duration instead of passing zero to future_base_time().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64545", "url": "https://ubuntu.com/security/CVE-2026-64545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net, bpf: check master for NULL in xdp_master_redirect() xdp_master_redirect() dereferences the result of netdev_master_upper_dev_get_rcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency. The reach guard only checks netif_is_bond_slave(). On bond slave release bond_upper_dev_unlink() drops the upper-master adjacency before clearing IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window still passes netif_is_bond_slave() while master is already NULL, and faults on master->flags at offset 0xb0: BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdp_master_redirect (net/core/filter.c:4432) Call Trace: xdp_master_redirect (net/core/filter.c:4432) bpf_prog_run_generic_xdp (include/net/xdp.h:700) do_xdp_generic (net/core/dev.c:5608) __netif_receive_skb_one_core (net/core/dev.c:6204) process_backlog (net/core/dev.c:6319) __napi_poll (net/core/dev.c:7729) net_rx_action (net/core/dev.c:7792) handle_softirqs (kernel/softirq.c:622) __dev_queue_xmit (include/linux/bottom_half.h:33) packet_sendmsg (net/packet/af_packet.c:3082) __sys_sendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt The missing check dates back to the original code; commit 1921f91298d1 (\"net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master\") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72418", "url": "https://ubuntu.com/security/CVE-2026-72418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: prevent connlimit drops for early confirmed ct Commit 69894e5b4c5e (\"netfilter: nft_connlimit: update the count if add was skipped\") introduced a regression where packets for valid connections are dropped when using connlimit for soft-limiting scenarios. The issue occurs when a new connection reuses a socket currently in the TIME_WAIT state. In this scenario, the connection tracking entry is evaluated as already confirmed. Previously, __nf_conncount_add() assumed that if a connection was confirmed and did not originate from the loopback interface, it should skip the addition and return -EEXIST. Skipping the addition triggers a garbage collection run that cleans up the TIME_WAIT connection. Consequently, the active connection count drops to 0, which xt_connlimit mishandles, leading to the false rejection of the perfectly valid new connection. Fix this by replacing the interface check with protocol-agnostic state checks. We now skip the tree insertion and preserve the lockless garbage collection optimization only if the connection is IPS_ASSURED. This allows early-confirmed setup packets (such as reused TIME_WAIT sockets or locally generated SYN-ACKs) to be properly evaluated and counted without falsely dropping. The goto check_connections path is maintained to ensure these setup packets are deduplicated correctly. This has been tested with slowhttptest and HTTP server configured locally to ensure we are not breaking soft-limiting scenarios for local or external connections. In addition, it was tested with a OVS zone limit too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72421", "url": "https://ubuntu.com/security/CVE-2026-72421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't ignore error route in local/main tables. When CONFIG_IP_MULTIPLE_TABLES is enabled but no rule is added, fib_lookup() performs route lookup directly on two tables. Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table: # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache Once a random rule is added, the error route is respected: # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host Let's fix the inconsistent behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64538", "url": "https://ubuntu.com/security/CVE-2026-64538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix null-ptr-deref in fib6_nh_mtu_change(). fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown() clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(), but this re-fetch is unguarded; nexthop-backed routes survive addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is nulled. Return 0 when idev is NULL, matching rt6_mtu_change_route() and the fib6_mtu() fix in commit 5ad509c1fdad (\"ipv6: Fix null-ptr-deref in fib6_mtu().\"). Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6_nh_mtu_change+0x203/0x990 rt6_mtu_change_route+0x141/0x1d0 __fib6_clean_all+0xd0/0x160 rt6_mtu_change+0xb4/0x100 ndisc_router_discovery+0x24b5/0x2cb0 icmpv6_rcv+0x12e9/0x1710 ipv6_rcv+0x39b/0x410", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64546", "url": "https://ubuntu.com/security/CVE-2026-64546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72428", "url": "https://ubuntu.com/security/CVE-2026-72428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack slot index in nospec checks check_stack_write_fixed_off() computes the byte slot for a fixed-offset stack write as -off - 1, and records each written byte in slot_type[] with (slot - i) % BPF_REG_SIZE. The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a 4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates bytes 7..4. That can leave the second half-slot write without nospec_result even though the bytes being overwritten still require sanitization. Use the same slot index in the sanitization pre-check that the write path uses when updating slot_type[].", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72433", "url": "https://ubuntu.com/security/CVE-2026-72433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak This needs to test for nonzero retval.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72435", "url": "https://ubuntu.com/security/CVE-2026-72435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer() Sashiko pointed out that kfree_rcu() was called before rcu_assign_pointer() in handling the comment extension. Fix the order so that rcu_assign_pointer() called first.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72441", "url": "https://ubuntu.com/security/CVE-2026-72441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: fix kernel-infoleak in dgram_recvmsg() KMSAN reported a kernel-infoleak in move_addr_to_user(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925 ... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739 The issue occurs because the `pan_id` field of `struct ieee802154_addr` is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`. The execution flow is as follows: 1. `__ieee802154_rx_handle_packet()` declares a local `struct ieee802154_hdr hdr` on the stack. 2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse the source and destination addresses into this structure. 3. If the address mode is `IEEE802154_ADDR_NONE`, `ieee802154_hdr_get_addr()` previously only set the `mode` field, leaving the `pan_id` field containing uninitialized stack memory. 4. This uninitialized `pan_id` is later copied into a `struct sockaddr_ieee802154` in `dgram_recvmsg()` via `ieee802154_addr_to_sa()`. 5. Finally, `move_addr_to_user()` copies the socket address structure to user space, leaking the uninitialized bytes. Fix this by using `memset` to zero out the address structure in `ieee802154_hdr_get_addr()` when the mode is `IEEE802154_ADDR_NONE`.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72447", "url": "https://ubuntu.com/security/CVE-2026-72447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: hold socket lock when dumping endpoints in sctp_diag SCTP_DIAG endpoint dumping was traversing endpoint address lists without holding lock_sock(), while those lists could change concurrently via socket operations (e.g., bindx changes). This creates a race where nla_reserve() counts addresses under RCU protection, but the subsequent copy may see fewer entries, potentially leaking uninitialized memory to userspace. Fix this by: - Taking a reference on each endpoint during hash traversal - Moving socket operations (lock_sock()) outside read_lock_bh() - Serializing address list access during dump - Reworking sctp_for_each_endpoint() to support restart-based traversal with (net, pos) tracking Also: - Add WARN_ON_ONCE() for inconsistent address counts - Fix idiag_states filtering for LISTEN vs association cases - Skip dumping endpoints being freed (ep->base.dead) - Move dump position tracking into iterator, removing cb->args[4] and its comment for sctp_ep_dump()., - Update the comment for cb->args[4] and remove the comment for unused cb->args[5] for sctp_sock_dump(). Note: traversal is restart-based and may re-scan buckets multiple times, but this is acceptable due to small bucket sizes and required to support sleeping-safe callbacks. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64553", "url": "https://ubuntu.com/security/CVE-2026-64553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: psample: fix info leak in PSAMPLE_ATTR_DATA psample open codes nla_put() presumably to avoid wiping the data with 0s just to override it with packet data. This open coding is missing clearing the pad, however, each netlink attr is padded to 4B and data_len may not be divisible by 4B.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72448", "url": "https://ubuntu.com/security/CVE-2026-72448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix leak of SQ timestamp buffer on teardown The send-queue timestamp ring is allocated with qmem_alloc() when timestamping is used, but otx2_free_sq_res() never freed sq->timestamps, leaking that memory across ifdown and device removal. Add the missing qmem_free() alongside the other SQ companion buffers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72450", "url": "https://ubuntu.com/security/CVE-2026-72450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate selector family and prefixlen during match syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72459", "url": "https://ubuntu.com/security/CVE-2026-72459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: aa_label_alloc use aa_label_free on alloc failure aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init(). Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72460", "url": "https://ubuntu.com/security/CVE-2026-72460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72476", "url": "https://ubuntu.com/security/CVE-2026-72476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix possible use after free In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72479", "url": "https://ubuntu.com/security/CVE-2026-72479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: mma8452: handle I2C read error(s) in mma8452_read() Currently, If i2c_smbus_read_i2c_block_data() fails but mma8452_set_runtime_pm_state() succeeds, mma8452_read() returns 0. As a result, the caller mma8452_read_raw() assumes the read was successful and proceeds to use a buffer containing uninitialized stack memory. Add proper checking of the I2C read return value and propagate errors to the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72481", "url": "https://ubuntu.com/security/CVE-2026-72481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: ak8975: fix potential kernel stack memory leak Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72483", "url": "https://ubuntu.com/security/CVE-2026-72483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72484", "url": "https://ubuntu.com/security/CVE-2026-72484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: video: avoid double free on video register failure comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72489", "url": "https://ubuntu.com/security/CVE-2026-72489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: nvec: fix use-after-free in nvec_rx_completed() In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72492", "url": "https://ubuntu.com/security/CVE-2026-72492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in same_client_has_lease() same_client_has_lease() returns an opinfo pointer from ci->m_op_list after dropping ci->m_lock without taking a reference. smb_grant_oplock() then dereferences that pointer in copy_lease() and when checking breaking_cnt. A concurrent close can remove the old lease from ci->m_op_list and drop the last reference before the caller uses the returned pointer, leading to a use-after-free. Take a reference when same_client_has_lease() selects an existing lease, drop any previous match while scanning, and release the returned reference in smb_grant_oplock() after copying the lease state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72502", "url": "https://ubuntu.com/security/CVE-2026-72502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF) When MTU is large, ip6_default_advmss() can return IPV6_MAXPLEN (65535). This is interpreted by TCP as mss_clamp, allowing the MSS to reach 65535. However, 0xFFFF is also used as a magic value GSO_BY_FRAGS in the kernel. If a TCP packet with gso_size=0xFFFF is passed to skb_segment(), it will be mistakenly treated as GSO_BY_FRAGS, leading to a NULL pointer dereference because local TCP packets do not use frag_list. Fix this by returning min(IPV6_MAXPLEN, GSO_BY_FRAGS - 1) (65534) from ip6_default_advmss() when MTU is large. Also update the stale comment in ip6_default_advmss() which suggested that IPV6_MAXPLEN is returned to mean \"any MSS\".", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74256", "url": "https://ubuntu.com/security/CVE-2026-74256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check start and len are u32, so \tu64 last = start + len; evaluates start + len in 32-bit and wraps before storing it in last. The bounds check \tif (start >= offset + l || last > msg->sg.size) \t\treturn -EINVAL; can then be passed with an out-of-range start/len, after which the pop loop runs off the end of the scatterlist and sk_msg_shift_left() calls put_page() on the empty msg->sg.end slot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:sk_msg_shift_left net/core/filter.c:2957 [inline] RIP: 0010:____bpf_msg_pop_data net/core/filter.c:3103 [inline] RIP: 0010:bpf_msg_pop_data+0x753/0x1a10 net/core/filter.c:2984 Call Trace: bpf_prog_4cc92c278f4d5d56+0x1b1/0x1e8 bpf_prog_run_pin_on_cpu+0x107/0x320 include/linux/filter.h:746 sk_psock_msg_verdict+0x357/0x7f0 net/core/skmsg.c:934 tcp_bpf_send_verdict net/ipv4/tcp_bpf.c:420 [inline] tcp_bpf_sendmsg+0x766/0x1ae0 net/ipv4/tcp_bpf.c:583 __sock_sendmsg+0x153/0x1c0 net/socket.c:802 __sys_sendto+0x326/0x430 net/socket.c:2265 __x64_sys_sendto+0xe3/0x100 net/socket.c:2268 do_syscall_64+0x14c/0x480 entry_SYSCALL_64_after_hwframe+0x77/0x7f Widen the addition with a (u64) cast so the bound is evaluated in 64-bit and a len near U32_MAX no longer wraps below msg->sg.size. While here, change pop from int to u32. It counts bytes against the unsigned scatterlist lengths and can never be negative, so the signed type only invites sign-confusion in the pop loop.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64548", "url": "https://ubuntu.com/security/CVE-2026-64548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data() When the scatterlist ring is full or nearly full, bpf_msg_push_data() enters a copy fallback path and computes copy + len for the page allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING and both are u32, a crafted len can wrap the sum to a small value, causing an undersized allocation followed by an out-of-bounds memcpy. BUG: unable to handle page fault for address: ffffed104089a402 Oops: Oops: 0000 [#1] SMP KASAN NOPTI Call Trace: __asan_memcpy (mm/kasan/shadow.c:105) bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) bpf_prog_9ed8b5711920a7d7+0x2e/0x36 sk_psock_msg_verdict (net/core/skmsg.c:934) tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) __sys_sendto (net/socket.c:2206) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add an overflow check before the allocation.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74262", "url": "https://ubuntu.com/security/CVE-2026-74262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcm: use WRITE_ONCE() when changing lower socket callbacks kcm_attach() replaces a live lower TCP socket's sk_data_ready and sk_write_space callbacks with KCM handlers, and kcm_unattach() restores them later. Those callback-pointer updates are still plain stores even though the same fields can be read and invoked concurrently on other CPUs. If another CPU observes an older callback snapshot after the live field has already been restored, callback execution can run with a mismatched target and sk_user_data state, leading to stale or misdirected wakeups. Use WRITE_ONCE() for the callback replacement and restore operations so these shared callback fields follow the same visibility contract already established by the earlier 4022 fixes.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74265", "url": "https://ubuntu.com/security/CVE-2026-74265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: initialize gdma queue id to INVALID_QUEUE_ID mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74276", "url": "https://ubuntu.com/security/CVE-2026-74276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: xilinx: use FIFO occupancy register to determine buffer size The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. When a SPI transaction wants to write the amount of the FIFO size or more bytes, the following happens, for example with 16 bytes FIFO size: The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and starts the SPI hardware and goes sleep. The hardware then shifts out 17 bytes (FIFO + shift register) and simultaneously reads bytes into the RX FIFO, but it only has 16 places, so it looses one byte. Then TX FIFO empty asserts, wakes the driver again, which has a fast path and reads 16 bytes from the RX FIFO, but before reading the last 17th byte (which is lost) it does this: \tsr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); \tif (!(sr & XSPI_SR_RX_EMPTY_MASK)) { \t\txilinx_spi_rx(xspi); \t\trx_words--; \t} It reads the status register and checks if the RX FIFO is not empty. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74279", "url": "https://ubuntu.com/security/CVE-2026-74279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: cavium/cpt - fix DMA cleanup using wrong loop index The sg_cleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74280", "url": "https://ubuntu.com/security/CVE-2026-74280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/octeontx - fix DMA cleanup using wrong loop index The sg_cleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74281", "url": "https://ubuntu.com/security/CVE-2026-74281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74282", "url": "https://ubuntu.com/security/CVE-2026-74282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: prevent snt_unacked underflow on CONN_ACK tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: \ttsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74283", "url": "https://ubuntu.com/security/CVE-2026-74283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74284", "url": "https://ubuntu.com/security/CVE-2026-74284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: Don't make class passive twice update_vf() is called from two places for the same class during a single dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last packets while dequeuing: 1. The child calls qdisc_tree_reduce_backlog(), which, now that the child is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns the class passive (cl_nactive is decremented up the hierarchy). 2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time) to charge the dequeued bytes. On the second call the class is already passive, but its child qdisc is still empty, so update_vf() arms go_passive again: if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1; The leaf is then skipped by the cl_nactive == 0 check inside the loop, which does not clear go_passive, so the stale go_passive propagates to the parent and decrements its cl_nactive a second time. A parent that still has other active children is driven to cl_nactive == 0 and removed from the vttree, even though those siblings are still backlogged. They are never dequeued again and the qdisc stalls. Fix this by only arming go_passive when the class is actually active, so an already-passive class no longer triggers a second passive transition. The byte accounting (cl->cl_total += len) still runs for every ancestor, so dequeued bytes continue to be counted exactly once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64537", "url": "https://ubuntu.com/security/CVE-2026-64537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: reject invalid CCM interval at configuration time ccm_tx_work_expired() re-arms itself via queue_delayed_work() using the configured exp_interval converted by interval_to_us(). When exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range, interval_to_us() returns 0, causing the worker to fire immediately in a tight loop that allocates skbs until OOM. Fix this by validating exp_interval at configuration time: - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the netlink policy so userspace cannot set an invalid value. - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not yet been configured (defaults to 0 from kzalloc).", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74288", "url": "https://ubuntu.com/security/CVE-2026-74288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fib_rules: Don't dump dying fib_rule in fib_rules_dump(). rocker_router_fib_event() calls fib_rule_get() during RCU dump. If the fib_rule is dying, refcount_inc() will complain about it. Let's call refcount_inc_not_zero() in fib_rules_dump().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74292", "url": "https://ubuntu.com/security/CVE-2026-74292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tegra: tegra210_ahub: Validate written enum value tegra_ahub_put_value_enum() reads e->values[item[0]] before checking whether item[0] is within the enum item range. The existing check therefore happens too late to prevent an out-of-range read of the values array. Move the check before the array access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74293", "url": "https://ubuntu.com/security/CVE-2026-74293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: fsl_audmix: Validate written enum values fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src() convert the user-provided enum item with snd_soc_enum_item_to_val() before checking whether the item is within the enum's item count. The generic snd_soc_put_enum_double() helper performs that validation, but these callbacks use the converted value first: the clock-source path tests it with BIT(), and the output-source path indexes the prms transition table with it. Reject out-of-range enum items before converting them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74295", "url": "https://ubuntu.com/security/CVE-2026-74295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: hdac_hdmi: Validate written enum value hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range. An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74297", "url": "https://ubuntu.com/security/CVE-2026-74297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix undefined shift of user RQ WQE size set_rq_size() computes the RQ WQE size as \"1 << rq_wqe_shift\" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74305", "url": "https://ubuntu.com/security/CVE-2026-74305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tighten cgroup storage cookie checks for prog arrays The fix in commit abad3d0bad72 (\"bpf: Fix oob access in cgroup local storage\") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74312", "url": "https://ubuntu.com/security/CVE-2026-74312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: validate virtqueue index in mmap and fault paths vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74313", "url": "https://ubuntu.com/security/CVE-2026-74313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: hold vduse_lock across IDR lookup in open path vduse_dev_open() looks up struct vduse_dev through the IDR and then acquires dev->lock only after vduse_lock has been dropped. This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the same object from the IDR and free it before the open path locks the device, leading to a use-after-free. Close this race by keeping vduse_lock held until dev->lock has been acquired in the open path, matching the lock ordering already used by the destroy path.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74320", "url": "https://ubuntu.com/security/CVE-2026-74320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, \"mode\", &len) is just written over either the static \"640x480-16@60\" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74321", "url": "https://ubuntu.com/security/CVE-2026-74321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 (\"btrfs: refactor __btrfs_run_delayed_refs loop\") but were unintentionally lost afterwards.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74327", "url": "https://ubuntu.com/security/CVE-2026-74327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmalloc: fix NULL pointer dereference in is_vm_area_hugepages() find_vm_area() can return NULL if the given address is not a valid vmalloc area. Check the return value before dereferencing it to avoid a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74329", "url": "https://ubuntu.com/security/CVE-2026-74329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: unregister PM notifier on watchdog unregister watchdog_register_device() registers wdd->pm_nb when WDOG_NO_PING_ON_SUSPEND is set, but watchdog_unregister_device() does not remove it. This leaves an embedded notifier block on the PM notifier chain after the watchdog device has been unregistered. A later suspend/resume notification can then call watchdog_pm_notifier() with a stale watchdog_device pointer, or at minimum after wdd->wd_data has been cleared by watchdog_dev_unregister(). Unregister the PM notifier before tearing down the watchdog device.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74330", "url": "https://ubuntu.com/security/CVE-2026-74330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: fix lockless traversals of ->s_children Having the parent directory locked protects entries from removal by another thread, but it does *not* protect cursors from being moved around by lseek() - or freed, for that matter.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74331", "url": "https://ubuntu.com/security/CVE-2026-74331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix recursive lock in device_cache_fw_images() A recursive locking deadlock can occur in the firmware loader's power management notification handler. During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock. For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread. The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock. Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74339", "url": "https://ubuntu.com/security/CVE-2026-74339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Clear variable event pointer on read snd_seq_read() copies a queued variable-length event header to userspace before expanding the payload. Queued variable-length events use SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first extension cell. The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the copy, but it leaves data.ext.ptr untouched. A userspace sequencer client can therefore write a direct variable event to itself and read back the extension-cell kernel address from the returned header. Clear the temporary header pointer before copy_to_user(). The original queued event remains unchanged and is still passed to snd_seq_expand_var_event(), so payload expansion keeps using the internal chain.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74340", "url": "https://ubuntu.com/security/CVE-2026-74340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74346", "url": "https://ubuntu.com/security/CVE-2026-74346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74348", "url": "https://ubuntu.com/security/CVE-2026-74348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: require a ref for locking_state debugfs open debug_lockres_open() copies inode->i_private into struct debug_lockres and debug_lockres_release() later drops that pointer with dlm_put(). That only works if open successfully pins the struct dlm_ctxt. Today open calls dlm_grab(dlm) but ignores its return value. Once the last domain unregister has removed the context from dlm_domains, dlm_grab() returns NULL, yet open still stores the raw pointer and returns success. The later release path is outside the debugfs removal barrier, so it can call dlm_put() after dlm_free_ctxt_mem() has freed the context. KASAN reports this as a slab-use-after-free in dlm_put() called from debug_lockres_release(). Fail the open when dlm_grab() cannot acquire the reference and unwind the seq_file private state before returning. That keeps locking_state from handing out a file descriptor whose release path does not own the dlm_ctxt. The buggy scenario involves two paths, with each column showing the order within that path: locking_state debugfs open: last domain unregister: 1. debug_lockres_open() reads 1. dlm_unregister_domain() calls inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() calls 2. shutdown removes the dlm_ctxt from dlm_grab(dlm) and gets NULL. dlm_domains. 3. open still stores the raw dlm 3. final teardown reaches pointer in dl->dl_ctxt and dlm_free_ctxt_mem() and frees it. returns success. 4. debug_lockres_release() later calls dlm_put(dl->dl_ctxt). Validation reproduced this kernel report: KASAN slab-use-after-free in dlm_put+0x82/0x200 RIP: 0033:0x7f4d349bc9e0 The buggy address belongs to the object at ffff888103a3c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 816 bytes inside of freed 2048-byte region [ffff888103a3c000, ffff888103a3c800) Write of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) dlm_put+0x82/0x200 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) kasan_check_range+0x105/0x1b0 (?:?) debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) dlm_put+0x9/0x200 (?:?) debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) full_proxy_release+0x67/0x90 (?:?) __fput+0x1df/0x4b0 (?:?) do_raw_spin_lock+0x10f/0x1b0 (?:?) fput_close_sync+0xd2/0x170 (?:?) __x64_sys_close+0x55/0x90 (?:?) do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87) irqentry_exit+0xac/0x6e0 (?:?) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Freed by task stack: kasan_save_stack+0x33/0x60 (?:?) kasan_save_track+0x14/0x30 (?:?) kasan_save_free_info+0x3b/0x60 (?:?) __kasan_slab_free+0x5f/0x80 (?:?) kfree+0x30f/0x580 (?:?) dlm_put+0x1ce/0x200 (?:?) dlm_unregister_domain+0xf6/0xb30 (?:?) o2cb_cluster_disconnect+0x6b/0x90 (?:?) ocfs2_cluster_disconnect+0x41/0x70 (?:?) ocfs2_dlm_shutdown+0x1c4/0x220 (?:?) ocfs2_dismount_volume+0x38a/0x550 (?:?) generic_shutdown_super+0xc3/0x220 (?:?) kill_block_super+0x29/0x60 (?:?) deactivate_locked_super+0x66/0xe0 (?:?) cleanup_mnt+0x13d/0x210 (?:?) task_work_run+0xfa/0x170 (?:?) exit_to_user_mode_loop+0xd6/0x430 (?:?) do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74349", "url": "https://ubuntu.com/security/CVE-2026-74349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject FITRIM ranges shorter than a cluster ocfs2_trim_mainbm() trims the global bitmap in cluster units, but its too-short range validation only checks sb->s_blocksize. On filesystems with a cluster size larger than the block size, a FITRIM range that is at least one block but shorter than one cluster is accepted and shifted down to len == 0. The later start + len - 1 and len -= ... arithmetic then underflows and can drive trimming past the requested range. Reject ranges shorter than s_clustersize instead. That preserves the existing -EINVAL behavior for requests that cannot discard even one allocation unit and keeps zero-cluster trims out of the group walk.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74351", "url": "https://ubuntu.com/security/CVE-2026-74351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74359", "url": "https://ubuntu.com/security/CVE-2026-74359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs_lookup(): don't leave ->s_dentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74363", "url": "https://ubuntu.com/security/CVE-2026-74363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs commit 4f375ade6aa9 (\"bpf: Avoid RCU context warning when unpinning htab with internal structs\") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.). This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime(). KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags) The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74379", "url": "https://ubuntu.com/security/CVE-2026-74379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax/kmem: account for partial discontiguous resource upon removal When dev_dax_kmem_probe() partially succeeds (at least one range is mapped) but a subsequent range fails request_mem_region() or add_memory_driver_managed(), the probe silently continues, ultimately returning success, but with the corresponding range resource NULL'ed out. dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the underlying resource exists. When remove_memory() is called later, it returns 0 because the memory was never added which causes dev_dax_kmem_remove() to incorrectly assume the (nonexistent) resource can be removed and attempts cleanup on a NULL pointer. Fix this by skipping these ranges altogether, noting that these cases are considered success, such that the cleanup is still reached when all actually-added ranges are successfully removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74382", "url": "https://ubuntu.com/security/CVE-2026-74382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74390", "url": "https://ubuntu.com/security/CVE-2026-74390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr->pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don't overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74395", "url": "https://ubuntu.com/security/CVE-2026-74395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list before initializing the fields used by the shared error path. If eventfd_ctx_fdget() then fails, the unwind path dereferences event_sub->ev_file in uverbs_uobject_put() and calls subscribe_event_xa_dealloc() with an unset xa_key_level1. subscribe_event_xa_alloc() creates the XA entry exactly once for a given key_level1, on the first occurrence of that key. The unwind path must therefore call subscribe_event_xa_dealloc() exactly once for it as well. Enforce that by adding devx_key_in_sub_list() and calling subscribe_event_xa_dealloc() only when the last matching pending entry is being cleaned up.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74399", "url": "https://ubuntu.com/security/CVE-2026-74399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64544", "url": "https://ubuntu.com/security/CVE-2026-64544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents pefile_digest_pe_contents() computes the trailing-data hash length as pelen - (hashed_bytes + certs_size). A crafted PE can make the addition exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB. This is passed to crypto_shash_update() which reads out of bounds and panics on unmapped vmalloc guard pages. BUG: unable to handle page fault for address: ffffc900038d8000 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152) Call Trace: __sha256_update (lib/crypto/sha256.c:208) crypto_sha256_update (crypto/sha256.c:142) verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436) kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151) __do_sys_kexec_file_load (kernel/kexec_file.c:406) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Validate that the addition does not overflow and the result does not exceed pelen before the subtraction. Return -ELIBBAD on failure.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74402", "url": "https://ubuntu.com/security/CVE-2026-74402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix blocking and non-blocking rng logic The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74408", "url": "https://ubuntu.com/security/CVE-2026-74408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: fix OOB access from firmware tx status queue ID ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74410", "url": "https://ubuntu.com/security/CVE-2026-74410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478), causing an out-of-bounds read from the pre-allocated DMA buffer when skb_put_data copies new_len bytes. The USB transport already validates this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the PCIe path does not. Add a check that new_len does not exceed the DMA buffer size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74416", "url": "https://ubuntu.com/security/CVE-2026-74416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix memory leak in radeon_ring_restore() on lock failure radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74424", "url": "https://ubuntu.com/security/CVE-2026-74424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix NULL pointer dereference for a console without vc_data fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data. Keep fb_display[i].mode set only while the console has a vc_data. Check vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74426", "url": "https://ubuntu.com/security/CVE-2026-74426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: fix NULL pointer dereference in afs_get_tree() afs_alloc_sbi() uses kzalloc for memory allocation. And, if ctx->dyn_root is not null, as->cell and as->volume are null. In trace_afs_get_tree() they are dereferenced. KASAN error message: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550 include/trace/events/afs.h:1365 Call Trace: trace_afs_get_tree include/trace/events/afs.h:1365 [inline] afs_get_tree+0x922/0x1350 fs/afs/super.c:599 vfs_get_tree+0x8e/0x300 fs/super.c:1572 do_new_mount fs/namespace.c:3011 [inline] path_mount+0x14a5/0x2220 fs/namespace.c:3341 do_mount fs/namespace.c:3354 [inline] __do_sys_mount fs/namespace.c:3562 [inline] __se_sys_mount fs/namespace.c:3539 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3539 do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74438", "url": "https://ubuntu.com/security/CVE-2026-74438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun4i-ss - Remove insecure and unused rng_alg Remove sun4i_ss_rng, as it is insecure and unused: - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing locking and has a buffer overflow. sun4i_ss_prng_generate() fails to fill the entire buffer with cryptographic random bytes, because it rounds the destination length down and also doesn't actually wait for the hardware to be ready before pulling bytes from it. - No user of this code is known. It's usable only theoretically via the \"rng\" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen and discovered by Atuin - Automated Vulnerability Discovery Engine There's no point in fixing all these vulnerabilities individually when this is unused code, so let's just remove it.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74578", "url": "https://ubuntu.com/security/CVE-2026-74578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_skcipher - force synchronous processing on trees without ctx->state The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx->iv directly into the skcipher request. After io_submit() the socket lock is dropped and the request is processed asynchronously, so a concurrent sendmsg(ALG_SET_IV) can overwrite ctx->iv and make the in-flight request run under an attacker-controlled IV. For CTR/stream modes this is IV/keystream reuse and lets an unprivileged user recover the plaintext of a concurrent operation. Snapshotting ctx->iv into per-request storage for the async path is not sufficient. For ciphers with statesize == 0 - which includes cbc and ctr - the MSG_MORE inter-chunk IV chaining is carried solely by the in-place req->iv writeback, which a snapshot redirects into per-request memory that af_alg_free_resources() releases on completion, silently producing wrong output. Writing the IV back from the completion callback instead is not possible either: that would require lock_sock() there, but the callback can run in softirq/atomic context, so it must not sleep. Make the operation synchronous instead, which removes both the IV race and any writeback race. This is equivalent to the upstream resolution, commit fcc77d33a34c (\"net: Remove support for AIO on sockets\"), which removed the AIO socket path across net/ entirely and so produces the same end state for this file. This patch deviates from that commit deliberately: rather than removing AIO socket support tree-wide, which would be far too invasive for stable, it removes only the AIO branch in crypto/algif_skcipher.c. io_submit() now completes synchronously; AF_ALG async is rarely used in practice. The -EIOCBQUEUED check in skcipher_recvmsg() is now dead but harmless, and is left alone to keep the fix minimal. Tested on 6.6.y: attacker IV injection dropped from 2296/200000 to 0/200000 after the change; MSG_MORE chunked CTR output bit-identical to single-shot.", "cve_priority": "medium", "cve_public_date": "2026-08-16 09:16:00 UTC" }, { "cve": "CVE-2026-64600", "url": "https://ubuntu.com/security/CVE-2026-64600", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.", "cve_priority": "medium", "cve_public_date": "2026-07-23 06:16:00 UTC" }, { "cve": "CVE-2026-64187", "url": "https://ubuntu.com/security/CVE-2026-64187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fail recovery on a committed log item with no regions If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367)", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64266", "url": "https://ubuntu.com/security/CVE-2026-64266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before returning from fuse_ref_folio() fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues. Fix this by locking the request in fuse_ref_folio() before returning.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64268", "url": "https://ubuntu.com/security/CVE-2026-64268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64269", "url": "https://ubuntu.com/security/CVE-2026-64269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64271", "url": "https://ubuntu.com/security/CVE-2026-64271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: touchwin - reset the packet index on every complete packet tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: \ttw->data[tw->idx++] = data; \tif (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { \t\t... \t\ttw->idx = 0; \t} The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64273", "url": "https://ubuntu.com/security/CVE-2026-64273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - bound the device-reported force-feedback effect index iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: \ti = data[1] & 0x7f; \tif (data[1] & 0x80) { \t\tif (!test_and_set_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) \t\t\t... \t} else if (test_and_clear_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) { \t\t... \t} The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate \"effect started/stopped\" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64274", "url": "https://ubuntu.com/security/CVE-2026-64274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: goodix - clamp the device-reported contact count goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer \tu8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: \tts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64275", "url": "https://ubuntu.com/security/CVE-2026-64275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: elan_i2c - prevent division by zero and arithmetic underflow The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64276", "url": "https://ubuntu.com/security/CVE-2026-64276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64277", "url": "https://ubuntu.com/security/CVE-2026-64277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64279", "url": "https://ubuntu.com/security/CVE-2026-64279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter deregistration race Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name).", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64604", "url": "https://ubuntu.com/security/CVE-2026-64604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f No functional change intended.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64296", "url": "https://ubuntu.com/security/CVE-2026-64296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: \tif (++order == 2) \t\tuniname = p_uniname->name; \telse \t\tuniname += EXFAT_FILE_NAME_LEN; \tlen = exfat_extract_uni_name(ep, entry_uniname); \tname_len += len; \tunichar = *(uniname+len); \t*(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba (\"exfat: check if filename entries exceeds max filename length\")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64298", "url": "https://ubuntu.com/security/CVE-2026-64298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: include MAY_WRITE in open permission mask for O_TRUNC POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64299", "url": "https://ubuntu.com/security/CVE-2026-64299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64303", "url": "https://ubuntu.com/security/CVE-2026-64303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64306", "url": "https://ubuntu.com/security/CVE-2026-64306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: drbg - Fix returning success on failure in CTR_DRBG drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64312", "url": "https://ubuntu.com/security/CVE-2026-64312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64313", "url": "https://ubuntu.com/security/CVE-2026-64313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ecc - Fix carry overflow in vli multiplication The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows. The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow. When commit 3c4b23901a0c (\"crypto: ecdh - Add ECDH software support\") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation. Add proper handling for this boundary by accounting for the carry from the lower addition.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64315", "url": "https://ubuntu.com/security/CVE-2026-64315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64316", "url": "https://ubuntu.com/security/CVE-2026-64316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64317", "url": "https://ubuntu.com/security/CVE-2026-64317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge \"SL\" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64318", "url": "https://ubuntu.com/security/CVE-2026-64318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: aix: bound the pp_count scan to the ppe array aix_partition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array: \tint numpps = be16_to_cpu(pvd->pp_count); \t... \tfor (i = 0; i < numpps; i += 1) { \t\tstruct ppe *p = pvd->ppe + i; \t\t... \t\tlp_ix = be16_to_cpu(p->lp_ix); pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk pp_count. pp_count is an unvalidated __be16 read straight from the descriptor, so a crafted AIX image with pp_count larger than 1016 drives the loop to read pvd->ppe[i] past the end of the allocation (up to 65535 entries, ~2 MB out of bounds). The partition scan runs without mounting anything, when a block device with a crafted AIX/IBM partition table appears (an attacker-supplied image attached with losetup -P, or a device auto-scanned by udev), via msdos_partition() -> aix_partition(). Clamp the scan to the number of entries the ppe[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64322", "url": "https://ubuntu.com/security/CVE-2026-64322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when \tsizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: \tfor (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) { \t\tstruct sparingEntry *entry = &st->mapEntry[i]; \t\t... entry->origLocation ... \t} in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64323", "url": "https://ubuntu.com/security/CVE-2026-64323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate VAT header length against the VAT inode size udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size: \tmap->s_type_specific.s_virtual.s_start_offset = \t\tle16_to_cpu(vat20->lengthHeader); \tmap->s_type_specific.s_virtual.s_num_entries = \t\t(sbi->s_vat_inode->i_size - \t\t\tmap->s_type_specific.s_virtual.s_start_offset) >> 2; lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the \"block > s_num_entries\" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads \t((__le32 *)(iinfo->i_data + s_start_offset))[block] so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read. Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64324", "url": "https://ubuntu.com/security/CVE-2026-64324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate free block extents against the partition length udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64330", "url": "https://ubuntu.com/security/CVE-2026-64330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64331", "url": "https://ubuntu.com/security/CVE-2026-64331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running `usbip attach` from the host would cause the guest to oops with the following backtrace: Call trace: vep_dequeue+0x1c/0xe4 (P) usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34 __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64332", "url": "https://ubuntu.com/security/CVE-2026-64332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ulpi: fix memory leak on registration failure The allocated device name is never freed on early ULPI device registration failures. Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64333", "url": "https://ubuntu.com/security/CVE-2026-64333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64334", "url": "https://ubuntu.com/security/CVE-2026-64334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix hard lockup on disconnect If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled. Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect. This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64335", "url": "https://ubuntu.com/security/CVE-2026-64335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix broken rx after throttle If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound). Clear the throttle flags and submit the urb if needed when opening the port.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64336", "url": "https://ubuntu.com/security/CVE-2026-64336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan_pda: fix information leak The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspan_pda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer. Fix the information leak by making sure that keyspan_pda_write_start() returns zero on success as intended.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64337", "url": "https://ubuntu.com/security/CVE-2026-64337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: unmap request DMA on queue failure mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails. Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64338", "url": "https://ubuntu.com/security/CVE-2026-64338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: misc: uss720: unregister parport on probe failure uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered. Leaving the port registered is more than a private allocation leak: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is about to release. Undo the pre-announce registration in the get_1284_register() failure branch before jumping to the common private-data cleanup path. Clear priv->pp first, matching the disconnect path and avoiding a stale pointer in the private data. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64340", "url": "https://ubuntu.com/security/CVE-2026-64340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: legousbtower: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64342", "url": "https://ubuntu.com/security/CVE-2026-64342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: iowarrior: fix use-after-free on disconnect Submitted write URBs are not stopped on close() and therefore need to be stopped unconditionally on disconnect() to avoid use-after-free in the completion handler.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64343", "url": "https://ubuntu.com/security/CVE-2026-64343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ldusb: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64344", "url": "https://ubuntu.com/security/CVE-2026-64344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64346", "url": "https://ubuntu.com/security/CVE-2026-64346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: Fix use-after-free in gadget_match_driver The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usb_del_gadget() frees the udc memory (e.g., via mode-switch work) while gadget_match_driver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed: [39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr : gadget_match_driver+0x34/0x60 ... [39430.911890][ T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][ T1171] Workqueue: events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usb_gadget_release() routine to the core. When the gadget is added, usb_add_gadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usb_gadget_release() drops the reference to the udc and then calls the gadget's release routine.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64347", "url": "https://ubuntu.com/security/CVE-2026-64347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler The OTG branch of composite_setup() falls back to the first configuration when none is selected: \tif (cdev->config) \t\tconfig = cdev->config; \telse \t\tconfig = list_first_entry(&cdev->configs, \t\t\t\t\t struct usb_configuration, list); \tif (!config) \t\tgoto done; \t... \tmemcpy(req->buf, config->descriptors[0], value); list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the \"if (!config)\" check is dead. When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer. cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch. Use list_first_entry_or_null() so the existing check does its job.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64350", "url": "https://ubuntu.com/security/CVE-2026-64350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info() cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and stream_rings array, but leaves stream_ctx_array allocated. Free the stream context array before falling through to the stream_rings cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64351", "url": "https://ubuntu.com/security/CVE-2026-64351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: bound RX frame length in kalmia_rx_fixup() kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usb_packet_length to about 65530. That bypasses the usb_packet_length < ether_packet_length truncation path. The device-supplied ether_packet_length, a le16 up to 65535 read from header_start[2], then drives a memcmp() and the following skb_trim() and skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10, which is 14000 bytes. That is an out of bounds read. Require both the start and end framing headers to be present before subtracting them, on every loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64359", "url": "https://ubuntu.com/security/CVE-2026-64359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64360", "url": "https://ubuntu.com/security/CVE-2026-64360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64362", "url": "https://ubuntu.com/security/CVE-2026-64362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: lg-g15: cancel pending work on remove to fix a use-after-free lg_g15_data is allocated with devm and holds a work item. The report handlers schedule that work straight from device input. lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key, and lg_g510_leds_event() does it too. The worker dereferences the lg_g15_data back through container_of. The driver had no remove callback and never cancelled the work. So if a report scheduled the work and the keyboard was then unplugged, devres freed lg_g15_data while the work was still pending or running, and the worker touched freed memory. This is a use-after-free. It is reachable as a race on device unplug. Add a remove callback that cancels the work before devres frees the state. g15->work is only initialized for the models that schedule it (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the cancel on g15->work.func to avoid cancelling a work that was never set up. The g15 NULL test mirrors the one already in lg_g15_raw_event().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68091", "url": "https://ubuntu.com/security/CVE-2026-68091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: stop hardware after post-start probe failures wacom_parse_and_register() starts HID hardware before registering inputs and initializing pad LEDs/remotes. Those later steps can fail, but their error paths currently release Wacom resources without stopping the HID hardware. Route post-hid_hw_start() failures through hid_hw_stop() before releasing driver resources. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64370", "url": "https://ubuntu.com/security/CVE-2026-64370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference via get_pid() and stores it in timer.it.cpu.pid. If the subsequent posix_cpu_timer_set() call fails, the function returns immediately without calling posix_cpu_timer_del() to release the pid reference, causing a leak. Fix it by calling posix_cpu_timer_del() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64372", "url": "https://ubuntu.com/security/CVE-2026-64372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: pcc: fix use-after-free and double free in _OSC evaluation pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the two-phase _OSC negotiation. Between the two calls it freed output.pointer but left output.length unchanged. Since acpi_evaluate_object() treats a non-zero length with a non-NULL pointer as an existing buffer to write into, the second call wrote into freed memory (use-after-free). The subsequent kfree(output.pointer) at out_free then freed the same pointer a second time (double free). Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first result, so ACPICA allocates a fresh buffer for each phase independently.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64373", "url": "https://ubuntu.com/security/CVE-2026-64373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path. Unlike the normal system suspend path, the reboot path does not call freeze_processes(), so userspace processes and kernel threads remain active. This allows CPU hotplug operations to run concurrently with cpufreq_suspend(). The original code has no synchronization with CPU hotplug, leading to a race condition where governor_data can be freed by the hotplug path while cpufreq_suspend() is still accessing it, resulting in a null pointer dereference: Unable to handle kernel NULL pointer dereference Call Trace: do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200 Fix this by adding cpus_read_lock()/cpus_read_unlock() to cpufreq_suspend() to block CPU hotplug operations while suspend is in progress. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64374", "url": "https://ubuntu.com/security/CVE-2026-64374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64403", "url": "https://ubuntu.com/security/CVE-2026-64403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64408", "url": "https://ubuntu.com/security/CVE-2026-64408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: pin L2CAP connection during netdev registration bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64411", "url": "https://ubuntu.com/security/CVE-2026-64411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: terminate table name before find_table_lock() update_counters() and compat_update_counters() forward a user-supplied 32-byte table name to find_table_lock() without NUL-terminating it. On a lookup miss, find_inlist_lock() calls try_then_request_module(..., \"%s%s\", \"ebtable_\", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte. BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) __request_module (kernel/module/kmod.c:150) do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) update_counters (net/bridge/netfilter/ebtables.c:1440) do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573) nf_setsockopt (net/netfilter/nf_sockopt.c:101) ip_setsockopt (net/ipv4/ip_sockglue.c:1424) raw_setsockopt (net/ipv4/raw.c:847) __sys_setsockopt (net/socket.c:2393) ... compat_do_replace() shares the same unterminated name via compat_copy_ebt_replace_from_user(); terminate it there too so all find_table_lock() callers behave alike. The other callers already terminate the name after the copy.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64412", "url": "https://ubuntu.com/security/CVE-2026-64412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: module names must be null-terminated We need to explicitly check the length, else we may pass non-null terminated string to request_module().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64420", "url": "https://ubuntu.com/security/CVE-2026-64420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: cros_ec: Delay dev_set_drvdata() until probe success If ec_device_probe() fails, cros_ec_class_release releases memory for the cros_ec_dev structure. However, because the drvdata was already set, sub-drivers like cros_ec_typec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when cros_ec_typec attempts to access &typec->ec->ec->dev on a device that has already been released. Move dev_set_drvdata() to ensure that the pointer is only made available once all initialization steps have succeeded. sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' Call trace: sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... BUG: KASAN: invalid-access in __memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOT_MODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: events_unbound deferred_probe_work_func Call trace: __memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64422", "url": "https://ubuntu.com/security/CVE-2026-64422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP socket state. The sysctl is stored as an `int` but copied into the `u32` `tp->reordering` field for new sockets, so negative writes wrap to large values. With `tcp_mtu_probing=2`, the wrapped value can overflow the `tcp_mtu_probe()` size calculation and drive the MTU probing path into an out-of-bounds read. Route `tcp_reordering` writes through `proc_dointvec_minmax()` and require it to be at least 1. Also require `tcp_max_reordering` to be at least 1 so the configured maximum cannot become negative either. When registering the table for a non-init network namespace, relocate `extra2` pointers that refer into `init_net.ipv4` so the `tcp_reordering` upper bound follows that namespace's `tcp_max_reordering`. Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`. This keeps the send queue and window checks from being bypassed through signed integer overflow.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64423", "url": "https://ubuntu.com/security/CVE-2026-64423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: remove multicast group from hash table on device destruction When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through the multicast list and calls ip_ma_put() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mc_hash). Since the device remains published in dev->ip_ptr until after ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs. Fix this by unlinking the multicast group from mc_hash using ip_mc_hash_remove() before scheduling it for reclamation. BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276 Call Trace: dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 Allocated by task 2239: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40 __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300 Freed by task 0: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50 __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64425", "url": "https://ubuntu.com/security/CVE-2026-64425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 10dc95939817 (\"io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64429", "url": "https://ubuntu.com/security/CVE-2026-64429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: eic-sprd: use raw_spinlock_t in the irq startup path sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64430", "url": "https://ubuntu.com/security/CVE-2026-64430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid calling pci_irq_vector() from hardirq context ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive the vector number. pci_irq_vector() calls msi_get_virq() that takes a mutex and can therefore trigger \"scheduling while atomic\" splats: BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedule_preempt_disabled+0x28/0x50 __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf] __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64432", "url": "https://ubuntu.com/security/CVE-2026-64432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns In the analysis pass of $LogFile journal replay, log_replay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcns_follow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time: BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array: 1. dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow. 2. lrh->target_vcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge size_t. Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL. This mirrors the bounds-check pattern added in commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") and commit 0ca0485e4b2e (\"fs/ntfs3: validate rec->used in journal-replay file record check\").", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68090", "url": "https://ubuntu.com/security/CVE-2026-68090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) \treturn; obj = alloc(); \t\t\t\tif (!obj) { \t\t\t\t\t\t\t// Out of memory \tdebug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized \tif (!IS_ERR_OR_NULL(obj)) \treturn; if (!obj) { \tdebug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64435", "url": "https://ubuntu.com/security/CVE-2026-64435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: Fix data races of skb_queue_len() readers on audit_queue Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races. All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn() KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 value changed: 0x00000001 -> 0x00000000 ================================================================== Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side. [PM: line length tweak]", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64436", "url": "https://ubuntu.com/security/CVE-2026-64436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: initialize alg_key_len for IPComp states pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name: \tx->calg = kmalloc_obj(*x->calg); \tif (!x->calg) { \t\terr = -ENOMEM; \t\tgoto out; \t} \tstrcpy(x->calg->alg_name, a->name); \tx->props.calgo = sa->sadb_sa_encrypt; Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data. calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE: \txfrm_state_migrate() \t xfrm_state_clone_and_setup() \t x->calg = xfrm_algo_clone(orig->calg); \t kmemdup(orig, xfrm_alg_len(orig)); where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0): BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90 ___sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4) Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail. The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent. Initialize calg->alg_key_len to 0, matching the aalg/ealg branches.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64599", "url": "https://ubuntu.com/security/CVE-2026-64599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: amlogic - avoid double cleanup in meson_crypto_probe() When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker(). Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM. ================================================================== BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0 Read of size 8 at addr ff1100010c057a68 by task insmod/265 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? kthread_destroy_worker+0xb2/0xd0 ? kthread_destroy_worker+0xb2/0xd0 kasan_report+0xca/0x100 ? kthread_destroy_worker+0xb2/0xd0 kthread_destroy_worker+0xb2/0xd0 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto] platform_probe+0x99/0x140 really_probe+0x1c6/0x6a0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x248/0x310 ? acpi_driver_match_device+0xb0/0x100 driver_probe_device+0x48/0x210 ? __pfx___device_attach_driver+0x10/0x10 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x104/0x190 ? __pfx_bus_for_each_drv+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 __device_attach+0x19d/0x3b0 ? __pfx___device_attach+0x10/0x10 ? do_raw_spin_unlock+0x53/0x220 device_initial_probe+0x78/0xa0 bus_probe_device+0x5b/0x130 device_add+0xcfd/0x1430 ? __pfx_device_add+0x10/0x10 ? insert_resource+0x34/0x50 ? lock_release+0xc9/0x290 platform_device_add+0x24e/0x590 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro] meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro] do_one_initcall+0xc0/0x450 ? __pfx_do_one_initcall+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 ? __create_object+0x59/0x80 ? kasan_unpoison+0x27/0x60 do_init_module+0x27b/0x7d0 ? __pfx_do_init_module+0x10/0x10 ? kasan_quarantine_put+0x84/0x1d0 ? kfree+0x32c/0x510 ? load_module+0x561e/0x5ff0 load_module+0x54fe/0x5ff0 ? __pfx_load_module+0x10/0x10 ? security_file_permission+0x20/0x40 ? kernel_read_file+0x23d/0x6e0 ? mmap_region+0x235/0x4a0 ? __pfx_kernel_read_file+0x10/0x10 ? __file_has_perm+0x2c0/0x3e0 init_module_from_file+0x158/0x180 ? __pfx_init_module_from_file+0x10/0x10 ? __lock_acquire+0x45a/0x1ba0 ? idempotent_init_module+0x315/0x610 ? lock_release+0xc9/0x290 ? lock ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64440", "url": "https://ubuntu.com/security/CVE-2026-64440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB write in HT_caps_handler() HT_caps_handler() iterates pIE->length bytes and writes into HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct HT_caps_element). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlme_ext_info. Truncate the iteration count to the size of HT_caps.u.HT_cap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HT_caps_enable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64536", "url": "https://ubuntu.com/security/CVE-2026-64536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop The loop in is_ap_in_tkip() iterates over IEs without verifying that enough bytes remain before dereferencing the IE header or its payload: - pIE->element_id and pIE->length are read without checking that i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the buffer causes an OOB read. - For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12, which requires pIE->length >= 16. For WLAN_EID_RSN it compares pIE->data + 8, requiring pIE->length >= 12. Neither requirement is checked. Add the missing IE header and payload bounds checks and guard each data access with an explicit pIE->length minimum, matching the pattern established in update_beacon_info().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-64442", "url": "https://ubuntu.com/security/CVE-2026-64442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64443", "url": "https://ubuntu.com/security/CVE-2026-64443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the element_id byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64444", "url": "https://ubuntu.com/security/CVE-2026-64444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i < pkt_len. When a malicious AP sends an AssocResponse whose last IE has only one byte remaining in the frame (the element_id byte lands at pkt_len-1), the loop reads pIE->length from pframe[pkt_len], which is one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pkt_len, silently passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pkt_len.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64445", "url": "https://ubuntu.com/security/CVE-2026-64445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth() OnAuth() has two bugs in the shared-key authentication path. When the Privacy bit is set, rtw_wep_decrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtw_wep_decrypt(), length is computed as: length = len - WLAN_HDR_A3_LEN - iv_len and then passed as (length - 4) to crc32_le(). If len is less than WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative and, after the implicit cast to size_t, causes crc32_le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path. When processing a seq=3 response, rtw_get_ie() stores the Challenge Text IE length in ie_len, but the subsequent memcmp() always reads 128 bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64450", "url": "https://ubuntu.com/security/CVE-2026-64450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it (\"if (glen > dlen) break;\"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: \tthis_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), \t\t\t GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: \"if (glen > dlen) break;\" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means \"legacy peer without Selective ACK\", a distinct legitimate state.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64452", "url": "https://ubuntu.com/security/CVE-2026-64452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix NHC entry use-after-free on error path lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding lowpan_nhc_lock. If the descriptor has no uncompress callback, the error path drops the lock before printing nhc->name. lowpan_nhc_del() removes descriptors under the same lock and then relies on synchronize_net() before the owning module can be unloaded. That only waits for net RX RCU readers. lowpan_header_decompress() is also exported and can be reached from callers that are not necessarily covered by the net core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive path. This leaves a race where one task drops lowpan_nhc_lock in the error path, another task unregisters and frees the matching descriptor after synchronize_net() returns, and the first task then dereferences nhc->name for the warning. With the post-unlock window widened, KASAN reports: BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220 Read of size 8 lowpan_nhc_do_uncompression lowpan_header_decompress Fix this by printing the warning before dropping lowpan_nhc_lock, so the descriptor name is read while unregister is still excluded. The malformed packet is still rejected with -ENOTSUPP.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64454", "url": "https://ubuntu.com/security/CVE-2026-64454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: run gadget disconnect from sleepable suspend context dwc3_gadget_suspend() takes dwc->lock with IRQs disabled and then calls dwc3_disconnect_gadget(). For async callbacks that helper only uses plain spin_unlock()/spin_lock(), so the gadget ->disconnect() callback still runs with IRQs disabled and any sleepable callback trips Lockdep. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the dwc3_gadget_suspend() -> dwc3_disconnect_gadget() -> gadget_driver->disconnect() chain, and Lockdep reported: BUG: sleeping function called from invalid context gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] Keep the disconnect callback selection in one common helper, but add a sleepable suspend-side wrapper which snapshots the callback under dwc->lock and then runs it after spin_unlock_irqrestore(). The regular event path still uses the existing spin_unlock()/spin_lock() window.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64455", "url": "https://ubuntu.com/security/CVE-2026-64455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: chaoskey: Fix slab-use-after-free in chaoskey_release() The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: \tBUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) \tRead of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 \tHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 \tCall Trace: \t \t dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) \t print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) \t kasan_report (mm/kasan/report.c:595) \t dev_driver_string (drivers/base/core.c:2406) \t __dynamic_dev_dbg (lib/dynamic_debug.c:906) \t chaoskey_release (drivers/usb/misc/chaoskey.c:323) \t __fput (fs/file_table.c:510) \t fput_close_sync (fs/file_table.c:615) \t __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) \t do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) \t entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64456", "url": "https://ubuntu.com/security/CVE-2026-64456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: virtio: clamp device-reported used.len at copy_data() random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64189", "url": "https://ubuntu.com/security/CVE-2026-64189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64465", "url": "https://ubuntu.com/security/CVE-2026-64465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix sleep in atomic context in xhci_free_streams() When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64468", "url": "https://ubuntu.com/security/CVE-2026-64468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_free_transaction() In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64469", "url": "https://ubuntu.com/security/CVE-2026-64469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_thread_release() When a thread exits, binder_thread_release() walks its transaction stack to clear the t->from and t->to_proc that correspond with the exiting thread. However, a process dying in parallel might attempt to kfree some of these transactions. And if one of them has no associated t->to_proc, the t->to_proc->inner_lock will not be acquired. This means that transaction accesses in binder_thread_release() after t->to_proc has been cleared might race with binder_free_transaction() and cause a use-after-free error as reported by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798 Write of size 8 at addr ffff000016627500 by task X/715 CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...] Allocated by task 717 on cpu 18 at 67.267803s: __kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+0x554/0x8150 binder_thread_write+0xa30/0x4354 binder_ioctl+0x20f0/0x299c [...] Freed by task 202 on cpu 18 at 90.416221s: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_free_transaction+0x150/0x294 binder_send_failed_reply+0x398/0x6d8 binder_release_work+0x3e4/0x4ec binder_deferred_func+0xbd8/0x104c [...] ================================================================== In order to avoid this, make sure that binder_free_transaction() reads the t->to_proc under the transaction lock. This will serialize the transaction release with the accesses in binder_thread_release(). Plus, it matches the documented locking rules for @to_proc.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64470", "url": "https://ubuntu.com/security/CVE-2026-64470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on marvell probe failure Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64471", "url": "https://ubuntu.com/security/CVE-2026-64471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on registration failure Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64478", "url": "https://ubuntu.com/security/CVE-2026-64478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64483", "url": "https://ubuntu.com/security/CVE-2026-64483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. \tcount = be32_to_cpu(payload->sample_count); \tif (likely(count <= (length - 16) / 4)) \t\tisight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64484", "url": "https://ubuntu.com/security/CVE-2026-64484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es1938: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. snd_es1938_mixer() does not check the return value before dereferencing the pointer, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64487", "url": "https://ubuntu.com/security/CVE-2026-64487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every iteration it advances buf and subtracts the block size while looping on \"while (len)\". len is urb->actual_length. That value is supplied by the device and is not guaranteed to be a multiple of 16. When a final short block leaves len between 1 and 15, the loop runs once more, reads up to buf[15], and then does \"len -= TKS4_MSGBLOCK_SIZE\". As len is unsigned this underflows to a huge value. The loop then keeps iterating and walking buf far past the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus block id happens to be hit. Iterate only while a full message block is available. This stops the unsigned underflow and silently drops any trailing partial block, which carries no complete control value anyway. The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1 and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor urb->actual_length before dispatching.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64494", "url": "https://ubuntu.com/security/CVE-2026-64494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: fix runtime PM leak on read error gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the \"out\" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a \"goto out\" to ensure the reference is properly dropped on the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64495", "url": "https://ubuntu.com/security/CVE-2026-64495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: bmg160: bail out when bandwidth/filter is not in table bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: \tfor (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { \t\tif (bmg160_samp_freq_table[i].bw_bits == bw_bits) \t\t\tbreak; \t} \t*val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64496", "url": "https://ubuntu.com/security/CVE-2026-64496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64497", "url": "https://ubuntu.com/security/CVE-2026-64497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64602", "url": "https://ubuntu.com/security/CVE-2026-64602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: spear: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in spear_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, spear_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ spear_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64500", "url": "https://ubuntu.com/security/CVE-2026-64500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: lpc32xx: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64503", "url": "https://ubuntu.com/security/CVE-2026-64503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64504", "url": "https://ubuntu.com/security/CVE-2026-64504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer \tu16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: \tcount = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: \tif (samples && count > samples) \t\tcount = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: \tbmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64505", "url": "https://ubuntu.com/security/CVE-2026-64505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check for header Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68088", "url": "https://ubuntu.com/security/CVE-2026-68088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check to response query Add variable representations for BufLength and BufOffset in rndis_query_response(), and perform a length check on them. This is identical to how rndis_set_response() handles these parameters.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-53392", "url": "https://ubuntu.com/security/CVE-2026-53392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53402", "url": "https://ubuntu.com/security/CVE-2026-53402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font() When fbcon_do_set_font() fails (e.g., due to a memory allocation failure inside vc_resize() under heavy memory pressure), it jumps to the `err_out` label to roll back the console state. However, the current rollback logic forgets to restore the `hi_font` state, leading to a severe state machine corruption. Earlier in the function, `set_vc_hi_font()` might be called to change `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()` subsequently fails, the `err_out` path restores `vc_font.charcount` but entirely skips rolling back the `vc_hi_font_mask` and the screen buffer. This mismatch leaves the terminal in a desynchronized state. Because `vc_hi_font_mask` remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure. Fix this by adding the missing rollback logic for the `hi_font` mask and screen buffer in the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63810", "url": "https://ubuntu.com/security/CVE-2026-63810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Avoid mounting the bdev pseudo-filesystem in userspace The bdev pseudo-filesystem is an internal kernel filesystem with which userspace should not interfere. Unregister it so that userspace cannot even attempt to mount it. This fixes a bug [1] that occurs when attempting to access files, because the system call move_mount() uses pointers declared in the inode_operations structure, which for the bdev pseudo-filesystem are always equal to 0. `inode->i_op = &empty_iops;` [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:0x0 Call Trace: lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460 open_last_lookups fs/namei.c:3550 [inline] path_openat+0x953/0x2700 fs/namei.c:3780 do_filp_open+0x1c5/0x410 fs/namei.c:3810 do_sys_openat2+0x171/0x4d0 fs/open.c:1318 do_sys_open fs/open.c:1334 [inline] __do_sys_openat fs/open.c:1350 [inline] __se_sys_openat fs/open.c:1345 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68459", "url": "https://ubuntu.com/security/CVE-2026-68459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs() When we mount device w/ gc_merge mount option, we may suffer below potential deadlock: Kworker\t\t\t\t\tGC trehad\t\t\tTruncator - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback --- set writeback flag on folio - f2fs_outplace_write_data : cached folio in internal bio cache - f2fs_balance_fs - wake_up(gc_thread) : wake up gc thread to run foreground GC - finish_wait(fggc_wq) : wait on the waitqueue --- wait on GC thread to finish the work \t\t\t\t\t\t\t\t\t- truncate_inode_pages_range \t\t\t\t\t\t\t\t\t - __filemap_get_folio(, FGP_LOCK) --- lock folio \t\t\t\t\t\t\t\t\t - truncate_inode_partial_folio \t\t\t\t\t\t\t\t\t - folio_wait_writeback --- wait on writeback being cleared \t\t\t\t\t- do_garbage_collect \t\t\t\t\t - move_data_page \t\t\t\t\t - f2fs_get_lock_data_folio \t\t\t\t\t - lock on folio --- blocked on folio's lock In order to avoid such deadlock, let's call below functions to commit cached bios in GC_MERGE path of f2fs_balance_fs() as the same as we did in NOGC_MERGE path. - f2fs_submit_merged_write(sbi, DATA); - f2fs_submit_all_merged_ipu_writes(sbi);", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-68460", "url": "https://ubuntu.com/security/CVE-2026-68460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in f2fs_balance_fs() When the f2fs filesystem space is nearly exhausted, we encounter deadlock issues as below: INFO: task A:1890 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:A state:D stack:0 pid:1890 tgid:1626 ppid:1153 flags:0x00000204 Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 folio_wait_bit+0x20/0x38 folio_wait_writeback+0x54/0xc8 truncate_inode_partial_folio+0x70/0x1e0 truncate_inode_pages_range+0x1b0/0x450 truncate_pagecache+0x54/0x88 f2fs_file_write_iter+0x3e8/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task kworker/u8:11:2680853 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:11 state:D stack:0 pid:2680853 tgid:2680853 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 __filemap_get_folio+0x214/0x348 pagecache_get_page+0x20/0x70 f2fs_get_read_data_page+0x150/0x3e8 f2fs_get_lock_data_page+0x2c/0x160 move_data_page+0x50/0x478 do_garbage_collect+0xd38/0x1528 f2fs_gc+0x240/0x7e0 f2fs_balance_fs+0x1a0/0x208 f2fs_write_single_data_page+0x6e4/0x730 f2fs_write_cache_pages+0x378/0x9b0 f2fs_write_data_pages+0x2e4/0x388 do_writepages+0x8c/0x2c8 __writeback_single_inode+0x4c/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x200 INFO: task kworker/u8:8:2641297 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:8 state:D stack:0 pid:2641297 tgid:2641297 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_write_inode+0xf4/0x328 __writeback_single_inode+0x370/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x20 INFO: task B:1902 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:B state:D stack:0 pid:1902 tgid:1626 ppid:1153 flags:0x0000020c Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_map_blocks+0x94c/0x1110 f2fs_file_write_iter+0x228/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task sync:2769849 blocked for more than 120 seconds. Tainted: G ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63815", "url": "https://ubuntu.com/security/CVE-2026-63815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: bound i_inline_xattr_size for non-inline-xattr inodes When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: \tif (f2fs_sb_has_flexible_inline_xattr(sbi)) \t\tfi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: \tMAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) \tNR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) \taddrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: \twhile (bit_pos < d->max)\t\t/* fs/f2fs/dir.c */ \t\t... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ... Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files. Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63818", "url": "https://ubuntu.com/security/CVE-2026-63818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate orphan inode entry count f2fs_recover_orphan_inodes() trusts the orphan block entry_count when replaying orphan inodes from the checkpoint pack. A corrupted entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the ino[] array and interpret footer or following data as inode numbers. On a crafted image, mounting an unpatched kernel can drive orphan recovery into f2fs_bug_on() and panic the kernel. Validate entry_count before consuming entries so corrupted checkpoint data fails the mount with -EFSCORRUPTED and requests fsck instead. Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be recorded in the superblock s_errors[] field. This gives fsck a persistent hint even though mount-time orphan recovery failure may leave no chance to persist SBI_NEED_FSCK through a checkpoint.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68461", "url": "https://ubuntu.com/security/CVE-2026-68461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device property: initialize the remaining fields of fwnode_handle in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitialized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. While at it: initialize the remaining fields of struct fwnode_handle too just to be sure. [ Fix typo in commit message. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63829", "url": "https://ubuntu.com/security/CVE-2026-63829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper. Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs. Commit 8b484efd5cb4 (\"ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\") added the same check on the ioctl path. This adds it on RTM_NEWLINK.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2022-3114", "url": "https://ubuntu.com/security/CVE-2022-3114", "cve_description": "An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference.", "cve_priority": "negligible", "cve_public_date": "2022-12-14 21:15:00 UTC" }, { "cve": "CVE-2026-64514", "url": "https://ubuntu.com/security/CVE-2026-64514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is \"is this fault still WP-blocked?\". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says \"wait\", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns \"don't wait\" and lets the fault path retry.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53399", "url": "https://ubuntu.com/security/CVE-2026-53399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: release layout stid on setlease failure nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "high", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-31451", "url": "https://ubuntu.com/security/CVE-2026-31451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption. The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-43355", "url": "https://ubuntu.com/security/CVE-2026-43355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: bh1780: fix PM runtime leak on error path Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53139", "url": "https://ubuntu.com/security/CVE-2026-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23364", "url": "https://ubuntu.com/security/CVE-2026-23364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Compare MACs in constant time To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-46208", "url": "https://ubuntu.com/security/CVE-2026-46208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2023-54271", "url": "https://ubuntu.com/security/CVE-2023-54271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init blk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This happens because iocg->ioc is NULL. The field is initialized by ioc_pd_init() and never cleared. The NULL deref is caused by blkcg_activate_policy() installing blkg_policy_data before initializing it. blkcg_activate_policy() was doing the following: 1. Allocate pd's for all existing blkg's and install them in blkg->pd[]. 2. Initialize all pd's. 3. Online all pd's. blkcg_activate_policy() only grabs the queue_lock and may release and re-acquire the lock as allocation may need to sleep. ioc_weight_write() grabs blkcg->lock and iterates all its blkg's. The two can race and if ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a pd which is not initialized yet, leading to crash. The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c \"echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos\" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weight with the following patch applied: > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index fc49be622e05..38d671d5e10c 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol) > \t\tpd->online = false; > \t} > > + if (system_state == SYSTEM_RUNNING) { > + spin_unlock_irq(&q->queue_lock); > + ssleep(1); > + spin_lock_irq(&q->queue_lock); > + } > + > \t/* all allocated, init in the same order */ > \tif (pol->pd_init_fn) > \t\tlist_for_each_entry_reverse(blkg, &q->blkg_list, q_node) I don't see a reason why all pd's should be allocated, initialized and onlined together. The only ordering requirement is that parent blkgs to be initialized and onlined before children, which is guaranteed from the walking order. Let's fix the bug by allocating, initializing and onlining pd for each blkg and holding blkcg->lock over initialization and onlining. This ensures that an installed blkg is always fully initialized and onlined removing the the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53189", "url": "https://ubuntu.com/security/CVE-2026-53189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-52918", "url": "https://ubuntu.com/security/CVE-2026-52918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46160", "url": "https://ubuntu.com/security/CVE-2026-46160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix missing last_unlink_trans update when removing a directory When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path \"/mnt/dir1\" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] \t\tinode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] \t\trdev 0 sequence 2 flags 0x0 [445771.638102] \t\tatime 1775744884.0 [445771.660056] \t\tctime 1775744885.645502983 [445771.660058] \t\tmtime 1775744885.645502983 [445771.660060] \t\totime 1775744884.0 [445771.660062] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] \t\tindex 0 name_len 2 [445771.660066] \titem 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] \t\tlocation key (259 1 0) type 2 [445771.660070] \t\ttransid 9 data_len 0 name_len 4 [445771.660075] \titem 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] \t\tlocation key (257 1 0) type 2 [445771.660077] \t\ttransid 9 data_len 0 name_len 4 [445771.660078] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] \t\tlocation key (257 1 0) type 2 [445771.660080] \t\ttransid 9 data_len 0 name_len 4 [445771.660081] \titem 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] \t\tlocation key (259 1 0) type 2 [445771.660083] \t\ttransid 9 data_len 0 name_len 4 [445771.660084] \titem 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] \t\tinode generation 9 transid 9 size 8 nbytes 0 [445771.660087] \t\tblock group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] \t\trdev 0 sequence 2 flags 0x0 [445771.660089] \t\tatime 1775744885.641174097 [445771.660090] \t\tctime 1775744885.645502983 [445771.660091] \t\tmtime 1775744885.645502983 [445771.660105] \t\totime 1775744885.641174097 [445771.660106] \titem 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] \t\tindex 2 name_len 4 [445771.660108] \titem 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] \t\tlocation key (2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46292", "url": "https://ubuntu.com/security/CVE-2026-46292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46159", "url": "https://ubuntu.com/security/CVE-2026-46159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46191", "url": "https://ubuntu.com/security/CVE-2026-46191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46116", "url": "https://ubuntu.com/security/CVE-2026-46116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: \tif (x->km.seq) \t\thlist_del_rcu(&x->byseq); \tif (x->id.spi) \t\thlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46193", "url": "https://ubuntu.com/security/CVE-2026-46193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46180", "url": "https://ubuntu.com/security/CVE-2026-46180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31709", "url": "https://ubuntu.com/security/CVE-2026-31709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-46196", "url": "https://ubuntu.com/security/CVE-2026-46196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46291", "url": "https://ubuntu.com/security/CVE-2026-46291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46090", "url": "https://ubuntu.com/security/CVE-2026-46090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 (\"ALSA: aloop: Fix racy access at PCM trigger\") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46052", "url": "https://ubuntu.com/security/CVE-2026-46052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are unhashed Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume \"negative\" also means \"unhashed\": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45999", "url": "https://ubuntu.com/security/CVE-2026-45999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: \"outpages - inpages\" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46103", "url": "https://ubuntu.com/security/CVE-2026-46103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46056", "url": "https://ubuntu.com/security/CVE-2026-46056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46299", "url": "https://ubuntu.com/security/CVE-2026-46299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: \t========================= \tWARNING: held lock freed! \t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted \t------------------------- \tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! \tffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \t2 locks held by mount/174: \t#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 \t#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \tstack backtrace: \tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tCall Trace: \t \tdump_stack_lvl+0x82/0xd0 \tdebug_check_no_locks_freed+0x13a/0x180 \tkfree+0x16b/0x510 \t? hfsplus_fill_super+0xcb4/0x18a0 \thfsplus_fill_super+0xcb4/0x18a0 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x65f/0xc30 \t? srso_return_thunk+0x5/0x5f \t? pointer+0x4ce/0xbf0 \t? trace_contention_end+0x11c/0x150 \t? __pfx_pointer+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x79b/0xc30 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? vsnprintf+0x6da/0x1270 \t? srso_return_thunk+0x5/0x5f \t? __mutex_unlock_slowpath+0x157/0x740 \t? __pfx_vsnprintf+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? mark_held_locks+0x49/0x80 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? irqentry_exit+0x17b/0x5e0 \t? trace_irq_disable.constprop.0+0x116/0x150 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? __pfx_hfsplus_fill_super+0x10/0x10 \tget_tree_bdev_flags+0x302/0x580 \t? __pfx_get_tree_bdev_flags+0x10/0x10 \t? vfs_parse_fs_qstr+0x129/0x1a0 \t? __pfx_vfs_parse_fs_qstr+0x3/0x10 \tvfs_get_tree+0x89/0x320 \tfc_mount+0x10/0x1d0 \tpath_mount+0x5c5/0x21c0 \t? __pfx_path_mount+0x10/0x10 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? kmem_cache_free+0x307/0x540 \t? user_path_at+0x51/0x60 \t? __x64_sys_mount+0x212/0x280 \t? srso_return_thunk+0x5/0x5f \t__x64_sys_mount+0x212/0x280 \t? __pfx___x64_sys_mount+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \tdo_syscall_64+0x111/0x680 \tentry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7ffacad55eae \tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 \tRSP: 002b ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46169", "url": "https://ubuntu.com/security/CVE-2026-46169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45991", "url": "https://ubuntu.com/security/CVE-2026-45991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46065", "url": "https://ubuntu.com/security/CVE-2026-46065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46086", "url": "https://ubuntu.com/security/CVE-2026-46086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46003", "url": "https://ubuntu.com/security/CVE-2026-46003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46038", "url": "https://ubuntu.com/security/CVE-2026-46038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46026", "url": "https://ubuntu.com/security/CVE-2026-46026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46091", "url": "https://ubuntu.com/security/CVE-2026-46091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46078", "url": "https://ubuntu.com/security/CVE-2026-46078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46069", "url": "https://ubuntu.com/security/CVE-2026-46069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46021", "url": "https://ubuntu.com/security/CVE-2026-46021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46092", "url": "https://ubuntu.com/security/CVE-2026-46092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: check for PCI upstream bridge existence pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31700", "url": "https://ubuntu.com/security/CVE-2026-31700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31712", "url": "https://ubuntu.com/security/CVE-2026-31712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require minimum ACE size in smb_check_perm_dacl() Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31708", "url": "https://ubuntu.com/security/CVE-2026-31708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43350", "url": "https://ubuntu.com/security/CVE-2026-43350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: require a full NFS mode SID before reading mode bits parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31711", "url": "https://ubuntu.com/security/CVE-2026-31711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix active_num_conn leak on transport allocation failure Commit 77ffbcac4e56 (\"smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with \"Limit the maximum number of connections\". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31715", "url": "https://ubuntu.com/security/CVE-2026-31715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() The xfstests case \"generic/107\" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43492", "url": "https://ubuntu.com/security/CVE-2026-43492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting \"lzeros\" from the unsigned \"nbytes\". For this to happen, the scatterlist \"sgl\" needs to occupy more bytes than the \"nbytes\" parameter and the first \"nbytes + 1\" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than \"nbytes\", subtract the number of zeroes from \"nbytes\" and cause the underflow. When commit 2d4d1eea540b (\"lib/mpi: Add mpi sgl helpers\") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to \"nbytes\". However since commit 63ba4d67594a (\"KEYS: asymmetric: Use new crypto interface without scatterlists\"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger \"out_len\" than \"in_len\" and filling the \"in\" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the \"src\" and \"dst\" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "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.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-52933", "url": "https://ubuntu.com/security/CVE-2026-52933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix signed comparison in io_poll_get_ownership() io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2025-22026", "url": "https://ubuntu.com/security/CVE-2025-22026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2023-54125", "url": "https://ubuntu.com/security/CVE-2023-54125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Return error for inconsistent extended attributes ntfs_read_ea is called when we want to read extended attributes. There are some sanity checks for the validity of the EAs. However, it fails to return a proper error code for the inconsistent attributes, which might lead to unpredicted memory accesses after return. [ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0 [ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199 [ 138.931132] [ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4 [ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 138.947327] Call Trace: [ 138.949557] [ 138.951539] dump_stack_lvl+0x4d/0x67 [ 138.956834] print_report+0x16f/0x4a6 [ 138.960798] ? ntfs_set_ea+0x453/0xbf0 [ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200 [ 138.969793] ? ntfs_set_ea+0x453/0xbf0 [ 138.973523] kasan_report+0xb8/0x140 [ 138.976740] ? ntfs_set_ea+0x453/0xbf0 [ 138.980578] __asan_store4+0x76/0xa0 [ 138.984669] ntfs_set_ea+0x453/0xbf0 [ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10 [ 138.993390] ? kernel_text_address+0xd3/0xe0 [ 138.998270] ? __kernel_text_address+0x16/0x50 [ 139.002121] ? unwind_get_return_address+0x3e/0x60 [ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 139.010177] ? arch_stack_walk+0xa2/0x100 [ 139.013657] ? filter_irq_stacks+0x27/0x80 [ 139.017018] ntfs_setxattr+0x405/0x440 [ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10 [ 139.026569] ? kvmalloc_node+0x2d/0x120 [ 139.030329] ? kasan_save_stack+0x41/0x60 [ 139.033883] ? kasan_save_stack+0x2a/0x60 [ 139.037338] ? kasan_set_track+0x29/0x40 [ 139.040163] ? kasan_save_alloc_info+0x1f/0x30 [ 139.043588] ? __kasan_kmalloc+0x8b/0xa0 [ 139.047255] ? __kmalloc_node+0x68/0x150 [ 139.051264] ? kvmalloc_node+0x2d/0x120 [ 139.055301] ? vmemdup_user+0x2b/0xa0 [ 139.058584] __vfs_setxattr+0x121/0x170 [ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10 [ 139.066282] __vfs_setxattr_noperm+0x97/0x300 [ 139.070061] __vfs_setxattr_locked+0x145/0x170 [ 139.073580] vfs_setxattr+0x137/0x2a0 [ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10 [ 139.080223] ? __kasan_check_write+0x18/0x20 [ 139.084234] do_setxattr+0xce/0x150 [ 139.087768] setxattr+0x126/0x140 [ 139.091250] ? __pfx_setxattr+0x10/0x10 [ 139.094948] ? __virt_addr_valid+0xcb/0x140 [ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330 [ 139.102688] ? debug_smp_processor_id+0x1b/0x30 [ 139.105985] ? kasan_quarantine_put+0x5b/0x190 [ 139.109980] ? putname+0x84/0xa0 [ 139.113886] ? __kasan_slab_free+0x11e/0x1b0 [ 139.117961] ? putname+0x84/0xa0 [ 139.121316] ? preempt_count_sub+0x1c/0xd0 [ 139.124427] ? __mnt_want_write+0xae/0x100 [ 139.127836] ? mnt_want_write+0x8f/0x150 [ 139.130954] path_setxattr+0x164/0x180 [ 139.133998] ? __pfx_path_setxattr+0x10/0x10 [ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10 [ 139.141299] ? debug_smp_processor_id+0x1b/0x30 [ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80 [ 139.150796] __x64_sys_setxattr+0x71/0x90 [ 139.155407] do_syscall_64+0x3f/0x90 [ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 139.163843] RIP: 0033:0x7f108cae4469 [ 139.166481] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc [ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469 [ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6 [ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618 [ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0 [ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15 ---truncated---", "cve_priority": "high", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2026-31449", "url": "https://ubuntu.com/security/CVE-2026-31449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: validate p_idx bounds in ext4_ext_correct_indexes ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level. If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read. Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "high", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43064", "url": "https://ubuntu.com/security/CVE-2026-43064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix not releasing workqueue on .release() The workqueue associated with an DSA/IAA device is not released when the object is freed.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1109.114 -proposed tracker (LP: #2165588)", "", " [ Ubuntu: 5.15.0-198.208 ]", "", " * jammy/linux: 5.15.0-198.208 -proposed tracker (LP: #2166457)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192)", " - Input: ims-pcu - fix logic error in packet reset", " - KVM: VMX: Make vmread_error_trampoline() uncallable from C code", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - RDMA/siw: Only check attrs->cap.max_send_wr in siw_create_qp", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ata: sata_dwc_460ex: remove variable num_processed", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/time: Fix sparse warnings", " - powerpc: remove the last remnants of cputime_t", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - ASoC: bt-sco: fix bt-sco-pcm-wb dai widget don't connect to the endpoint", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - hwmon: (occ) Add sysfs entry for IPS (Idle Power Saver) status", " - hwmon: (occ) Add sysfs entry for OCC mode", " - hwmon: (occ) Add sysfs entries for additional extended status bits", " - hwmon: (occ) Delay hwmon registration until user request", " - net: dpaa2-eth: assign priv->mac after dpaa2_mac_connect() call", " - wifi: mac80211: recalculate TIM when a station enters power save", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: stmmac: add tc flower filter for EtherType matching", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - raw: use more conventional iterators", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - x86/boot/compressed: Disable jump tables", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - proc: Fix broken error paths for namespace links", " - ice: use READ_ONCE() to access cached PHC time", " - raw: remove unused variables from raw6_icmp_error()", " - raw: fix a typo in raw_icmp_error()", " - media: uvcvideo: Implement dual stream quirk to fix loss of usb packets", " - media: uvcvideo: Fix sequence number when no EOF", " - HID: logitech-dj: Standardise hid_report_enum variable nomenclature", " - HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB", " write", " - HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report", " - net: qrtr: ns: Raise node count limit to 512", " - dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA", " - ASoC: max98095: fix missing IS_ERR() before PTR_ERR() on mclk lookup", " - ASoC: max98090: fix missing IS_ERR() before PTR_ERR() on mclk lookup", " - phy: zynqmp: Allow variation in refclk rate", " - phy-zynqmp: Postpone getting clock rate until actually needed", " - phy: zynqmp: fix clock error handling in xpsgtr_phy_init()", " - phy: zynqmp: fix runtime PM leak on probe allocation failure", " - drm/mediatek: Check CRTC state before freeing", " - assoc_array: trim the final shortcut word using the current chunk end", " - smb: client: fix buffer leaks in SMB1 read and write", " - net: bridge: mrp: fix Option TLV length in MRP_Test frames", " - hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors", " - hwmon: (adt7470) Fix cache updated before hardware write on I2C error", " - hwmon: (adt7470) Fix temperature alarm logic in hwmon_temp_read()", " - hwmon: (adt7470) Fix swapped PWM3 and PWM4 auto mode masks", " - hwmon: (adt7470) Use cached PWM frequency value", " - hwmon: (adt7470) Fix PWM auto temp state array and bounds check", " - powerpc/boot: Fix simpleboot CPU node lookup check", " - powerpc/boot: Fix treeboot-currituck CPU node lookup check", " - powerpc/boot: Fix treeboot-akebono CPU node lookup check", " - wifi: mac80211: validate individual TWT params before driver setup", " - hwmon: (pmbus) Fix return value from pmbus_update_byte_data()", " - net: phylink: put link_gpio if phylink_create fails", " - scsi: zfcp: Fix memory leak during adapter release by destroying", " gid_pn_req", " - net: sxgbe: check descriptor ring allocation failures", " - can: isotp: check register_netdevice_notifier() error in module init", " - tracing/mmiotrace: Reset dropped_count in mmio_reset_data()", " - octeontx2-pf: Set correct sequence for carrier off and tx queue stop", " - pinctrl: bm1880: add missing select GENERIC_PINCONF", " - mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk()", " - sctp: validate Adaptation Indication parameter length", " - audit: fix potential integer overflow in audit_log_n_string()", " - bpf: lwt: Fix dst reference leak on reroute failure", " - ALSA: lx6464es: fix period byte count for 16-bit streams", " - ALSA: pcm: wake linked drain waiters on unlink", " - ASoC: tas2562: fix DVC coefficient write order", " - ASoC: tas2562: fix broken entries in the volume lookup table", " - dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+", " - e1000: fix memory leak in e1000_probe()", " - ipvs: do not propagate one-packet flag to synced conns", " - net: ipv6: clear suppressed fib6 rule result", " - powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()", " - vxlan: re-fetch eth header after route_shortcircuit()", " - vxlan: unclone skb head before modifying eth header in", " route_shortcircuit()", " - tracing/filters: Fix false positive match in regex_match_full()", " - selftests/clone3: fix wild pointer access of getline due to missing init", " - sctp: reject stale cookies with mismatched verification tags", " - hwmon: (npcm750-pwm-fan): stop fan timer on device detach", " - i2c: amd-mp2: Unregister callback on adapter add failure", " - cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init()", " - s390/dasd: Fix potential NULL pointer dereference", " - phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask", " - phy: zynqmp: use read-modify-write for SERDES scrambler bypass", " - phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB", " - can: c_can: c_can_chip_config(): keep controller in init mode until", " bittiming is configured", " - can: j1939: transport: j1939_session_fresh_new(): initialize receive", " buffer", " - can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in", " kvaser_usb_hydra_get_busparams()", " - can: softing: fw_parse(): validate firmware record spans", " - drm/amdgpu: restore UMD profile pstate after runtime resume", " - drm/amdgpu: cap GTT size to physical RAM on APUs", " - HID: logitech-dj: Fix maxfield check in DJ short report validation", " - net: openvswitch: fix skb leak on flow key update failure during", " recirculation", " - mount: honour SB_NOUSER in the new mount API", " - s390/zcrypt: Fix missing mem scrub at clear key import in", " cca_clr2cipherkey()", " - nfs4: take a reference on the nfs_client when running FREE_STATEID", " - NFS: Pin the 'struct nfs_server' during a FREE_STATEID call", " - ARM: npcm: Fix OF node refcount leaks in SMP setup", " - bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor", " - bpf: Preserve pointer state for commuted arithmetic", " - net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in", " smc_llc_event_handler()", " - net/sched: cls_route: fix fastmap use-after-free on filter", " - net: hisilicon: hix5hd2_gmac: remove redundant NAPI delete", " - net/mlx5: fw_tracer, return NULL on create error", " - counter: microchip-tcb-capture: Fix DT channel validation", " - vhost/vdpa: reject overflowing PA map page counts on 32-bit", " - udp: fix potential use-after-free in tunnel segmentation", " - net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter", " - net/openvswitch: check Ethernet header length in key_extract()", " - selftests/ftrace: Add test case for GRP/ only input", " - selftests/ftrace: refactor eprobes test to fix argument checks", " - bnxt_en: Do not set EOP on RX AGG BDs on 5760X chips", " - bnxt_en: Disable EOP for TPA on all chips to prevent data corruption", " - bnxt_en: Fix PTP PPS setting bug", " - sctp: fix addip_serial increment on ASCONF_ACK allocation failure", " - tcp: fix TFO max_qlen accounting across reuseport migration", " - net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length", " - net: prestera: validate firmware header length", " - net: remove WARN_ON_ONCE() from sk_mc_loop()", " - net/smc: fix TOCTOU race between smc_listen_out() and listener close", " - net: qrtr: ns: Raise lookup limit to 128", " - net: thunderbolt: Tear down DMA paths before stopping the rings", " - ata: pata_sl82c105: fix bridge revision use-after-free", " - sctp: clear control chunk transport if it is being removed", " - tls: don't abort the connection on signal-interrupted sends", " - hwmon: (corsair-psu) fix possible out-of-bounds access on missing string", " termination", " - spi: spi-fsl-dspi: Avoid setup_accel logic for DMA transfers", " - Input: evdev - sanitize event type index when fetching event masks", " - ALSA: usb-audio: fix OOB write on Type II inbound URBs", " - usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()", " - thunderbolt: icm: Preserve USB4 proxy data-valid bit", " - usb: cdnsp: fix incorrect endian conversions for APB timeout register", " - usb: gadget: f_ncm: Use unsigned int for ndp_index", " - ima: fix out-of-bounds read in xattr_verify()", " - ipvs: add totalconns for dest", " - ipvs: properly update the overload flag on dest edit", " - ipvs: clear IPv4 options after rebasing tunnel ICMP errors", " - net/packet: reset the MAC header on the packet-socket transmit path", " - net: openvswitch: reallocate update replies for mismatched IDs", " - net: octeontx2-pf: Fix UB in shift operation", " - net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header", " - netfilter: ebt_nflog: pin the NFLOG backend", " - net: bridge: mrp: fix uninitialised bytes on the wire", " - vt: add permission check for KDSKBMETA ioctl", " - vt: stabilize tty reference in kbd_keycode with tty_port_tty_get", " - Input: evdev - fix information leak in evdev_pass_values()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - futex: Prevent robust futex exit race some more", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - fscrypt: Replace mk_users keyring with simple list", " - ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops", " - ipv4: fix use-after-free in fib_nhc_update_mtu()", " - serial: 8250_dma: Clear stale RX state on shutdown", " - staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie()", " - staging: rtl8723bs: fix OOB read in WMM_param_handler()", " - staging: rtl8723bs: fix missing shared-key auth challenge length check", " - staging: rtl8723bs: validate monitor transmit frame lengths", " - misc: fastrpc: fix channel ctx ref leak when session alloc fails", " - misc: fastrpc: fix memory leak in fastrpc_channel_ctx_free", " - ALSA: usx2y: bound the hwdep mmap fault offset", " - tracing: Fix race between update_event_fields and, event_define_fields", " - fbdev: bitblit: bound-check glyph index in bit_cursor()", " - ipv6: prevent in6_dev_get() from resurrecting inet6_dev", " - netfilter: bridge: release template ct on non-IP path", " - net: atlantic: free RX pages of consumed but not refilled buffers", " - net/sched: act_gact, act_police: range check the fallback control action", " - xdp: reject clones that overrun skb_shared_info tailroom", " - vxlan: do not arm the ageing timer on a device that is down", " - vsock/virtio: read virtqueues under worker locks", " - vsock/virtio: avoid refilling the RX queue after teardown", " - vhost: reset the vring metadata cache on vring reconfiguration", " - tipc: read le->link under the node lock in tipc_node_link_down()", " - Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\"", " - ipv6: fix Route Information option length validation", " - ip6_tunnel: clear skb2->cb[] in ip6ip6_err()", " - bpf, sockmap: Fix sk_redir use-after-free in send verdict", " - scsi: scsi_debug: Negate wrapped memcmp() result", " - sctp: keep chunk->transport in step with the list it is queued on", " - sctp: fix use-after-free of cached ASCONF chunk", " - sctp: clear new_transport when removing a peer", " - thunderbolt: Bound the DROM dual link port number before indexing", " sw->ports", " - Linux 5.15.216", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64582", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74468", " - gpio: pch: use raw_spinlock_t for the register lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74482", " - mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74443", " - drm/vmwgfx: bound DMA command body size against suffix pointer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74444", " - drm/vmwgfx: validate DRAW_PRIMITIVES header size before division", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74453", " - drm/vc4: Zero the tile state data array before each BIN job", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74455", " - can: peak_usb: validate uCAN receive record lengths", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74456", " - can: peak_usb: peak_usb_start(): fix double free of transfer buffer on", " URB submit error", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74457", " - can: peak_usb: add bounds check for USB channel index", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74458", " - can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received", " command extents", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74459", " - can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB", " resubmit failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74460", " - can: ems_usb: validate CPC message lengths", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74461", " - i2c: imx: Cancel hrtimer before clearing slave pointer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74463", " - i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock", " deadlock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74464", " - net: openvswitch: fix skb leak on flow key update failure during ct", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74465", " - net: openvswitch: fix potential UAF on meter attach failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68451", " - s390/zcrypt: Validate length for CCA ECC private key requests", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68452", " - s390/zcrypt: Validate length for CCA AES cipher key requests", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74467", " - s390/qeth: Check CAP_NET_ADMIN for private ioctls", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74469", " - sctp: prevent peer transport count overflow", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74471", " - tracing: Check return value of __register_event() in", " trace_module_add_events()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74473", " - vxlan: use pskb_network_may_pull() in route_shortcircuit()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74475", " - vxlan: use neigh_ha_snapshot() in route_shortcircuit()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74478", " - um: vector: fix use-after-free in vector_mmsg_rx()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74480", " - net: bridge: stop fast-leave after deleting a port group", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74481", " - mm/page_reporting: use system_freezable_wq to fix UAF during suspend", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74485", " - binfmt_misc: reject a flag character as the field delimiter", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74488", " - wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74490", " - tipc: avoid use-after-free in poll trace queue dumps", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74492", " - netfilter: ipset: do not update comments from kernel-side hash adds", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74493", " - net/smc: fix socket use-after-free during link group termination", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74495", " - igbvf: Fix leak in TX DMA error cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74497", " - ALSA: usb-audio: Clamp frame size in implicit-feedback mode", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74498", " - ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74499", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74505", " - ALSA: 6fire: Fix UAF at error handling during probe", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74507", " - Bluetooth: HIDP: validate numbered report payloads", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74508", " - Bluetooth: HIDP: reject frames without a transaction header", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74512", " - audit: fix potential use-after-free in audit_del_rule()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74518", " - mm/hugetlb: fix list corruption in allocate_file_region_entries()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74519", " - pinctrl: devicetree: don't free uninitialized dev_name on error path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74523", " - qede: sync udp_tunnel ports outside qede_lock in the recovery path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74525", " - net: sxgbe: free TX rings on RX allocation failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74540", " - Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74546", " - hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74547", " - hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74548", " - forcedeth: fix UAF of txrx_stats in nv_remove", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74549", " - hwmon: (nct6775-core) Prevent access to unsupported weight registers", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74556", " - scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection", " buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74557", " - scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74563", " - rds: tcp: hold the RCU lock across ipv6_chk_addr() in", " rds_tcp_laddr_check()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74579", " - netfilter: nft_payload: fix mask build for partial field offload", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74564", " - netfilter: xt_hashlimit: validate hashtable supports", " XT_HASHLIMIT_RATE_MATCH", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74566", " - keys: make keyring key-chunk byte order agree with", " keyring_diff_objects()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74567", " - keys: fix out-of-bounds read in keyring_get_key_chunk()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74569", " - netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in", " sip_help_tcp()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-43491", " - net: qrtr: ns: Limit the maximum server registration per node", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74577", " - net: mpls: initialize rtm_tos in mpls_getroute()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64543", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72123", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72019", " - macsec: don't read an unset MAC header in macsec_encrypt()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-52977", " - futex: Prevent lockup in requeue-PI during signal/ timeout wakeup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * seccomp filter leak in bpf_jit due to unreaped zombie process", " (LP: #2164699)", " - seccomp: release task filters when the task exits", " * 5.15 kernel selftest srv6_end_dt6_l3vpn_test.sh failure (LP: #1961566)", " - SAUCE: selftest/net: skip srv6_end_dt6_l3vpn_test.sh if iproute2 too old", " * 5.15 kernel selftest srv6_end_dt4_l3vpn_test.sh failure (LP: #1956562)", " - SAUCE: selftest/net: skip srv6_end_dt4_l3vpn_test.sh if iproute2 too old", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", " * mount08 from ubuntu_ltp_syscalls failed - TFAIL: mount(/proc/139835/fd/4)", " succeeded (LP: #2137199)", " - proc: proc_readfd() -> proc_fd_iterate()", " - proc: proc_readfdinfo() -> proc_fdinfo_iterate()", " - proc: add proc_splice_unmountable()", " - proc: block mounting on top of /proc//map_files/*", " - proc: block mounting on top of /proc//fd/*", " - proc: block mounting on top of /proc//fdinfo/*", " * Jammy update: v5.15.215 upstream stable release (LP: #2165170)", " - Linux 5.15.215", " * Jammy update: v5.15.215 upstream stable release (LP: #2165170) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Jammy update: v5.15.214 upstream stable release (LP: #2165166)", " - Linux 5.15.214", " * Jammy update: v5.15.213 upstream stable release (LP: #2165125)", " - Linux 5.15.213", " * Jammy update: v5.15.213 upstream stable release (LP: #2165125) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124)", " - nfc: llcp: protect nfc_llcp_sock_unlink() calls", " - net/sched: act_pedit: use NLA_POLICY for parsing 'ex' keys", " - dma-buf: remove unused dma-fence-unwrap.c (stable/linux-5.15.y only)", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: Convert to platform remove callback returning void", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - skmsg: convert struct sk_msg_sg::copy to a bitmap", " - f2fs: fix to detect corrupted meta ino", " - f2fs: adjust zone capacity when considering valid block count", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: fix listxattr handling of corrupted xattr entries", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - PCI: altera: Do not dispose parent IRQ mapping", " - PCI: host-common: Request bus reassignment when not probe-only", " - virtio-mmio: fix device release warning on module unload", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - fuse: fix device node leak in cuse_process_init_reply()", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - tools/mm/slabinfo: fix total_objects attribute name", " - net: dsa: tag_ksz: do not rely on skb_mac_header() in TX paths", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - [Config] Remove CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - afs: Fix further netns teardown to cancel the preallocation charger", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - thermal: hwmon: Fix critical temperature attribute removal", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Fix UAF in strset__add_str()", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ARM: imx3: Fix CCM node reference leak", " - ARM: imx31: Fix IIM mapping leak in revision check", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - mm/fake-numa: fix under-allocation detection in uniform split", " - lib/test_meminit: use && for bools", " - bpftool: Use libbpf error code for flow dissector query", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Introduce SNDRV_SEQ_IOCTL_USER_PVERSION ioctl", " - ALSA: seq: Add UMP support", " - [Config] Disable CONFIG_SND_SEQ_UMP=n", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - hwspinlock: qcom: avoid uninitialized struct members", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - bonding: 3ad: fix mux port state on oper down", " - selftests/bpf: Fix bpf_iter/task_vma test", " - s390/process: Fix kernel thread function pointer type", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - crypto: rng - Free default RNG on module exit", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - netfilter: nf_conncount: callers must hold rcu read lock", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: zero-initialize the fib lookup flow struct", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - veth: fix NAPI leak in XDP enable error path", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - qede: fix out-of-bounds check for cqe->len_list[]", " - rtnetlink: change nlk->cb_mutex role", " - rtnetlink: add RTNL_FLAG_DUMP_UNLOCKED flag", " - inet: allow ip_valid_fib_dump_req() to be called with RTNL or RCU", " - ipv6: remove RTNL protection from inet6_dump_fib()", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - net/sched: hhf: clear heavy-hitter state on reset", " - afs: Fix vllist leak", " - afs: Fix unchecked-length string display in debug statement", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - net: qualcomm: rmnet: add tx packets aggregation", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - octeontx2-af: debugfs: Add channel and channel mask.", " - octeontx2-af: Use hashed field in MCAM key", " - octeontx2-af: Exact match support", " - octeontx2-af: Exact match scan from kex profile", " - octeontx2-af: devlink configuration support", " - octeontx2-af: FLR handler for exact match table.", " - octeontx2-af: Drop rules for NPC MCAM", " - octeontx2-af: Allow mkex profile without DMAC and add L2M/L2B header", " extraction support", " - octeontx2-pf: Add additional checks while configuring ucast/bcast/mcast", " rules", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - regulator: core: Make regulator_lock_two() logic easier to follow", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_nat: reject unsupported target families", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - x86/boot: Reject too long acpi_rsdp= values", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: fix VLAN priority offset", " - mfd: tps6586x: Fix OF node refcount", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - proc: only bump parent nlink when registering directories", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - xfrm: use compat translator only for u64 alignment mismatch", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - time: Fix off-by-one in compat settimeofday() usec validation", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm-verity: increase sprintf buffer size", " - scsi: sg: Report request-table problems when any status is set", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - gpios: palmas: add .get_direction() op", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - hwmon: (asus_atk0110) Check package count before accessing element", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - wifi: mac80211: free ack status frame on TX header build failure", " - mtd: onenand: samsung: report DMA completion timeouts", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: imu: inv_icm42600: make timestamp module chip independent", " - iio: move inv_icm42600 timestamp module in common", " - iio: make invensense timestamp module generic", " - iio: imu: inv_mpu6050: use the common inv_sensors timestamp module", " - [Config] Enable CONFIG_IIO_INV_SENSORS_TIMESTAMP=m", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - cifs: Create a new shared file holding smb2 pdu definitions", " - cifs: remove check of list iterator against head past the loop body", " - smb2: small refactor in smb2_check_message()", " - cifs: remove unused server parameter from calc_smb_size()", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - staging: rtl8723bs: Fix indentation issues", " - staging: rtl8723bs: Fix space issues", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - staging: rtl8723bs: Remove redundant else branches.", " - staging: rtl8723bs: remove redundant braces in if statements", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use new GPIO line value setter callbacks", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()", " - cifs: Add tracing for the cifs_tcon struct refcounting", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger", " - ksmbd: destroy async_ida in ksmbd_conn_free()", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - X.509: Fix validation of ASN.1 certificate header", " - proc: use generic setattr() for /proc/$PID/net", " - proc: Move fdinfo PTRACE_MODE_READ check into the inode .permission", " operation", " - proc: rename proc_setattr to proc_nochmod_setattr", " - HID: add haptics page defines", " - treewide: Switch/rename to timer_delete[_sync]()", " - serial: 8250_mid: Remove 8250_pci usage", " - serial: 8250_mid: Disable DMA for selected platforms", " - xfs: Remove redundant assignment of mp", " - xfs: Remove dead code", " - xfs: use null daddr for unset first bad log block", " - hfs/hfsplus: prevent getting negative values of offset/length", " - xdp: introduce flags field in xdp_buff/xdp_frame", " - bpf: Convert lpm_trie.c to rqspinlock", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - usb: iowarrior: remove inherent race with minor number", " - drm/i2c/sil164: Drop no-op remove function", " - leds: lm3697: Remove duplicated error reporting in .remove()", " - leds: lm3601x: Improve error reporting for problems during .remove()", " - gpio: pca953x: Make platform teardown callback return void", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel-sha204a - Mark OF related data as maybe unused", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - crypto: qat - fix restarting state leak on allocation failure", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - ALSA: seq: Avoid confusion of aligned read size", " - iio: imu: inv_mpu6050: fix frequency setting when chip is off", " - iio: invensense: fix odr switching to same value", " - ALSA: seq: Skip event type filtering for UMP events", " - ALSA: seq: Check UMP support for midi_version change", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - Linux 5.15.212", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72282", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72068", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64301", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64304", " - crypto: qat - validate RSA CRT component lengths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64593", " - btrfs: do not trim a device which is not writeable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64594", " - usb: gadget: f_fs: initialize reset_work at allocation time", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68456", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64329", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64352", " - bpf: Allow LPM map access from sleepable BPF programs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64355", " - bpf: Reject fragmented frames in devmap", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64361", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64363", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64371", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64364", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64375", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64390", " - ksmbd: track the connection owning a byte-range lock", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-31610", " - ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64380", " - smb: client: harden POSIX SID length parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64379", " - smb: client: mask server-provided mode to 07777 in modefromsid", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64401", " - smb: client: resolve SWN tcon from live registrations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64381", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64206", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64413", " - netfilter: ebtables: zero chainstack array", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64428", " - gpio: sch: use raw_spinlock_t in the irq startup path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64438", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64441", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64461", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64446", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64448", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64462", " - PCI: altera: Fix resource leaks on probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64475", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64488", " - ALSA: aoa: check snd_ctl_new1() return value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64510", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64512", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68466", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68467", " - mtd: mchp23k256: use SPI match data for chip caps", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68469", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68474", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68475", " - reset: sunxi: fix memory region leak on ioremap failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68478", " - memstick: ms_block: reject a card that reports too many blocks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68479", " - Bluetooth: btrtl: validate firmware patch bounds", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72004", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72005", " - wifi: rt2x00: avoid full teardown before work setup in probe", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72010", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72013", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72021", " - ipvs: use parsed transport offset in SCTP state lookup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72022", " - llc: fix SAP refcount leak in llc_ui_autobind()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72024", " - mac802154: remove interfaces with RCU list deletion", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72025", " - s390/monwriter: Reject buffer reuse with different data length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72036", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72038", " - net: liquidio: fix BAR resource leak on PF number failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72039", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72229", " - batman-adv: clean untagged VLAN on netdev registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72232", " - batman-adv: ensure minimal ethernet header on TX", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72235", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72047", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72048", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72049", " - ieee802154: admin-gate legacy LLSEC dump operations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72052", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72054", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72055", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72056", " - net: ena: clean up XDP TX queues when regular TX setup fails", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72061", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72066", " - cpu: hotplug: Bound hotplug states sysfs output", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72067", " - cpu: hotplug: Preserve per instance callback errors", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72074", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72076", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72078", " - Input: ims-pcu - validate control endpoint type", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72079", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72081", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72082", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72086", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72088", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72102", " - dm_early_create: fix freeing used table on dm_resume failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72105", " - dm-log: fix a bitset_size overflow on 32bit machines", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72107", " - dm era: fix out-of-bounds memory access for non-zero start sector", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72108", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72109", " - net: sparx5: unregister blocking notifier on init failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72120", " - can: bcm: add missing rcu list annotations and operations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72122", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72126", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72133", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72135", " - tpm: Make the TPM character devices non-seekable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72136", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72138", " - xen/gntdev: fix error handling in ioctl", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72140", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72153", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72159", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72160", " - ocfs2: reject dinodes with non-canonical i_mode type", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72163", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72164", " - ocfs2: avoid moving extents to occupied clusters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72165", " - mtd: rawnand: fix condition in 'nand_select_target()'", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72166", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72167", " - mtd: rawnand: pl353: fix probe resource allocation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72171", " - mtd: slram: remove failed entries from the device list", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72181", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72182", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72193", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64532", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64533", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72195", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72197", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72215", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72218", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72219", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72223", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72224", " - nvdimm/btt: Free arenas on btt_init() error paths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72225", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72228", " - batman-adv: frag: fix primary_if leak on failed linearization", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72230", " - batman-adv: frag: free unfragmentable packet", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72231", " - batman-adv: tt: avoid request storms during pending request", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72233", " - batman-adv: bla: reacquire gw address after skb realloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72238", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72240", " - mfd: sm501: Fix reference leak on failed device registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72241", " - leds: uleds: Fix potential buffer overread", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72245", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64554", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72247", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72250", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72256", " - netfilter: xt_cluster: reject template conntracks in hash match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72264", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72265", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72267", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72268", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72269", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72270", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72271", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72272", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72274", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72275", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72276", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72297", " - net: atm: reject out-of-range traffic classes in QoS validation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72298", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72306", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72307", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72310", " - smb: client: fix overflow in passthrough ioctl bounds check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72314", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72316", " - dm era: fix NULL pointer dereference in metadata_open()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72319", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72326", " - net/sched: cake: reject overhead values that underflow length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64549", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64550", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72347", " - netfilter: xt_connmark: reject invalid shift parameters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72349", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72350", " - netfilter: xt_u32: reject invalid shift counts", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72351", " - gue: validate REMCSUM private option length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64547", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72371", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72374", " - afs: Fix callback service message parsers to pass through -EAGAIN", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72378", " - afs: Fix error code in afs_extract_vl_addrs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72389", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64540", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72392", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72396", " - hwmon: adm1275: Prevent reading uninitialized stack", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72400", " - seg6: validate SRH length before reading fixed fields", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72406", " - net: sungem: fix probe error cleanup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72409", " - net: mvneta: re-enable percpu interrupt on resume", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72414", " - net: dsa: sja1105: round up PTP perout pin duration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64545", " - net, bpf: check master for NULL in xdp_master_redirect()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72418", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72421", " - ipv4: fib: Don't ignore error route in local/main tables.", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64538", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64546", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72428", " - bpf: Fix stack slot index in nospec checks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72433", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72435", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72441", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72447", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64553", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72448", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72450", " - xfrm: validate selector family and prefixlen during match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72459", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72460", " - apparmor: check label build before no_new_privs test", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72476", " - dmaengine: Fix possible use after free", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72479", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72481", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72483", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72484", " - staging: most: video: avoid double free on video register failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72489", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72492", " - ksmbd: fix use-after-free in same_client_has_lease()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72502", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74256", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64548", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74262", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74265", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74276", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74279", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74280", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74281", " - tipc: reject inverted service ranges from peer bindings", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74282", " - tipc: prevent snt_unacked underflow on CONN_ACK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74283", " - tipc: require net admin for TIPCv2 netlink mutators", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74284", " - net/sched: sch_hfsc: Don't make class passive twice", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74287", " - sctp: validate embedded address parameter length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64537", " - bridge: cfm: reject invalid CCM interval at configuration time", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74288", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74292", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74293", " - ASoC: fsl: fsl_audmix: Validate written enum values", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74295", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74297", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74305", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74312", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74313", " - vduse: hold vduse_lock across IDR lookup in open path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74320", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74321", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74327", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74329", " - watchdog: unregister PM notifier on watchdog unregister", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74330", " - configfs: fix lockless traversals of ->s_children", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74331", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74339", " - ALSA: seq: Clear variable event pointer on read", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74340", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74346", " - RDMA/irdma: Fix OOB read during CQ MR registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74348", " - ocfs2/dlm: require a ref for locking_state debugfs open", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74349", " - ocfs2: reject FITRIM ranges shorter than a cluster", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74351", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74359", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74363", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74379", " - dax/kmem: account for partial discontiguous resource upon removal", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74382", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74390", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74395", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74399", " - evm: terminate and bound the evm_xattrs read buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64544", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74402", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74408", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74410", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74416", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74424", " - fbcon: fix NULL pointer dereference for a console without vc_data", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74426", " - afs: fix NULL pointer dereference in afs_get_tree()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74438", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74578", " - crypto: algif_skcipher - force synchronous processing on trees without", " ctx->state", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64600", " - xfs: resample the data fork mapping after cycling ILOCK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64187", " - xfs: fail recovery on a committed log item with no regions", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64266", " - fuse: re-lock request before returning from fuse_ref_folio()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64268", " - RDMA/siw: bound Read Response placement to the RREAD length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64269", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64271", " - Input: touchwin - reset the packet index on every complete packet", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64273", " - Input: iforce - bound the device-reported force-feedback effect index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64274", " - Input: goodix - clamp the device-reported contact count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64275", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64276", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64277", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64279", " - i2c: core: fix adapter deregistration race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64604", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64296", " - exfat: bound uniname advance in exfat_find_dir_entry()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64298", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64299", " - tracing: Prevent out-of-bounds read in glob matching", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64303", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64306", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64312", " - crypto: pcrypt - restore callback for non-parallel fallback", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64313", " - crypto: ecc - Fix carry overflow in vli multiplication", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64315", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64315 // CVE-2026-64316", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64317", " - isofs: bound Rock Ridge symlink components to the SL record", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64318", " - partitions: aix: bound the pp_count scan to the ppe array", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64322", " - udf: validate sparing table length as an entry count, not a byte count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64323", " - udf: validate VAT header length against the VAT inode size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64324", " - udf: validate free block extents against the partition length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64330", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64331", " - usbip: vudc: fix NULL deref in vep_dequeue()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64332", " - USB: ulpi: fix memory leak on registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64333", " - USB: serial: digi_acceleport: fix write buffer corruption", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64334", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64335", " - USB: serial: digi_acceleport: fix broken rx after throttle", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64336", " - USB: serial: keyspan_pda: fix information leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64337", " - usb: mtu3: unmap request DMA on queue failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64338", " - USB: misc: uss720: unregister parport on probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64340", " - USB: legousbtower: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64342", " - USB: iowarrior: fix use-after-free on disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64343", " - USB: ldusb: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64344", " - USB: idmouse: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64346", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64347", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64350", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64351", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64359", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64360", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64362", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68091", " - HID: wacom: stop hardware after post-start probe failures", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64370", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64372", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64373", " - cpufreq: Fix hotplug-suspend race during reboot", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64374", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64403", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64408", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64411", " - netfilter: ebtables: terminate table name before find_table_lock()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64412", " - netfilter: ebtables: module names must be null-terminated", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64420", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64422", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64423", " - ipv4: igmp: remove multicast group from hash table on device destruction", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64425", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64429", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64430", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64432", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68090", " - debugobjects: Plug race against a concurrent OOM disable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64435", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64436", " - net: af_key: initialize alg_key_len for IPComp states", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64599", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64440", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64536", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64442", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64443", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64444", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64445", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64450", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64452", " - 6lowpan: fix NHC entry use-after-free on error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64454", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64455", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64456", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64189", " - netfilter: ipset: fix race between dump and ip_set_list resize", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64465", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64468", " - binder: fix UAF in binder_free_transaction()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64469", " - binder: fix UAF in binder_thread_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64470", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64471", " - Bluetooth: btusb: fix use-after-free on registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64478", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64483", " - ALSA: firewire: isight: bound the sample count to the packet payload", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64484", " - ALSA: es1938: check snd_ctl_new1() return value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64487", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64494", " - iio: light: gp2ap002: fix runtime PM leak on read error", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64495", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64496", " - iio: event: Fix event FIFO reset race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64497", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64602", " - iio: adc: spear: Initialize completion before requesting IRQ", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64500", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64503", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64504", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64505", " - usb: gadget: function: rndis: add length check for header", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68088", " - usb: gadget: function: rndis: add length check to response query", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53392", " - NFSv4/flexfiles: reject zero filehandle version count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53402", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63810", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68459", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68460", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63815", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63818", " - f2fs: validate orphan inode entry count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68461", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63829", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2022-3114", " - clk: imx: Add check for kcalloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64514", " - userfaultfd: gate must_wait writability check on pte_present()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53399", " - nfsd: release layout stid on setlease failure", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - drm: Remove plane hsub/vsub alignment requirement for core helpers", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - selftests: forwarding: lib: Add helpers for checksum handling", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_VENDOR to minimize PHY ID table", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - parport: Fix race between port and client registration", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - wireguard: send: append trailer after expanding head", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate VMBus packet size in receive callback", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - HID: pass the buffer size to hid_report_raw_event", " - HID: core: Fix size_t specifier in hid_report_raw_event()", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - serial: dz: Fix bootconsole handover lockup", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - USB: serial: mct_u232: fix memory corruption with small endpoint", " - compiler-clang.h: Add __diag infrastructure for clang", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", " - time: Fix off-by-one in settimeofday() usec validation", " - KVM: arm64: Remove VPIPT I-cache handling", " - arm64: tlb: Allow XZR argument to TLBI ops", " - arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBI", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", " - net: mv643xx: fix OF node refcount", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - SAUCE: Revert \"net/tcp-md5: Fix MAC comparison to be constant-time\"", " - f2fs: fix to do sanity check on dcc->discard_cmd_cnt conditionally", " - smb: server: fix max_connections off-by-one in tcp accept path", " - arm64/mm: Enable batched TLB flush in unmap_hotplug_range()", " - rtw88: 8821ce: Disable PCIe ASPM L1 for 8821CE using chip ID", " - ALSA: aoa: Use guard() for mutex locks", " - ALSA: aoa: i2sbus: clear stale prepared state", " - media: rc: ttusbir: respect DMA coherency rules", " - ALSA: aoa: Skip devices with no codecs in i2sbus_resume()", " - sched: Use u64 for bandwidth ratio calculations", " - ALSA: core: Fix potential data race at fasync handling", " - net: qrtr: ns: Change servers radix tree to xarray", " - net: mctp: fix don't require received header reserved bits to be zero", " - randomize_kstack: Maintain kstack_offset per task", " - mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration", " - mtd: spi-nor: sst: Fix write enable before AAI sequence", " - can: ucan: fix typos in comments", " - printk: add print_hex_dump_devel()", " - usb: typec: tcpm: reset internal port states on soft reset AMS", " - usb: dwc3: Move GUID programming after PHY initialization", " - net: ipv4: stop checking crypto_ahash_alignmask", " - net: ipv6: stop checking crypto_ahash_alignmask", " - spi: syncuacer: fix controller deregistration", " - spi: sun4i: fix controller deregistration", " - spi: spi-ti-qspi: Convert to platform remove callback returning void", " - spi: ti-qspi: fix controller deregistration", " - spi: zynq-qspi: fix controller deregistration", " - spi: sun6i: fix controller deregistration", " - spi: tegra114: fix controller deregistration", " - spi: tegra20-sflash: fix controller deregistration", " - spi: uniphier: fix controller deregistration", " - mm/hugetlb_cma: round up per_node before logging it", " - spi: topcliff-pch: Convert to platform remove callback returning void", " - spi: topcliff-pch: fix controller deregistration", " - tracing/probes: Limit size of event probe to 3K", " - SAUCE: Revert \"smb: client: validate dacloffset before building DACL", " pointers\"", " - smb: client: Use FullSessionKey for AES-256 encryption key derivation", " - mptcp: pm: prio: skip closed subflows", " - mptcp: pm: ADD_ADDR rtx: resched blocked ADD_ADDR quicker", " - f2fs: fix incorrect file address mapping when inline inode is unwritten", " - f2fs: fix false alarm of lockdep on cp_global_sem lock", " - spi: st-ssc4: fix controller deregistration", " - spi: lantiq-ssc: fix controller deregistration", " - genetlink: Use internal flags for multicast groups", " - smb: client: require net admin for CIFS SWN netlink", " - Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 2", " - Bluetooth: MGMT: validate Add Extended Advertising Data length", " - qed: Use the bitmap API to simplify some functions", " - qed: fix double free in qed_cxt_tables_alloc()", " - Bluetooth: Consolidate code around sk_alloc into a helper function", " - Bluetooth: Init sk_peer_* on bt_sock_alloc", " - net: hsr: defer node table free until after RCU readers", " - ice: fix VF queue configuration with low MTU values", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ioam: add NULL check for idev in ipv6_hop_ioam()", " - use less confusing names for iov_iter direction initializers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - selftests: mptcp: drop nanoseconds width specifier", " - mptcp: do not drop partial packets", " - octeontx2-af: CGX: add bounds check to cgx_speed_mbps index", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - spi: qup: switch to use modern name", " - spi: qup: fix error pointer deref after DMA setup failure", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - phy: tegra: xusb: Disable trk clk when not in use", " - phy: tegra: xusb: Fix per-pad high-speed termination calibration", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - serial: samsung_tty: Use port lock wrappers", " - tty: serial: samsung: use u32 for register interactions", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: gadget: f_hid: tidy error handling in hidg_alloc", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - serial: altera_jtaguart: Use platform_get_irq_optional() to get the", " interrupt", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - tty: serial: qcom-geni-serial: remove unused symbols", " - tty: serial: qcom-geni-serial: align #define values", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - batman-adv: tp_meter: fix tp_num leak on kmalloc failure", " - SAUCE: Revert \"net/ipv6: ioam6: prevent schema length wraparound in", " trace fill\"", " - SAUCE: Revert \"nfsd: fix heap overflow in NFSv4.0 LOCK replay cache\"", " - ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6", " - selinux: enable genfscon labeling for securityfs", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: close TOCTOU race while computing rcv_wnd", " - fbdev: vt8500lcdfb: Fix dma_free_coherent() cpu_addr parameter", " - SAUCE: Revert \"apparmor: validate DFA start states are in bounds in", " unpack_pdb\"", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: validate default DFA states are in bounds", " - media: rc: ttusbir: fix inverted error logic", " - batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown", " - media: rc: igorplugusb: fix control request setup packet", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - batman-adv: tp_meter: fix race condition in send error reporting", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - Linux 5.15.210", " - drm/v3d: Store the active job inside the queue's state", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: tt: prevent TVLV entry number overflow", " - vfio/iommu_type1: replace kfree with kvfree", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - i2c: stub: Reject I2C block transfers with invalid length", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", " - xhci: fix memory leak regression when freeing xhci vdev devices depth", " first", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", " - virtiofs: fix UAF on submount umount", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - Revert \"ptp: add testptp mask test\"", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", " - kselftest/arm64: signal: Skip SVE signal test if not enough VLs", " supported", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: v: prevent OGM aggregation on disabled hardif", " - batman-adv: tp_meter: restrict number of unacked list entries", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - ring-buffer: Remove ring_buffer_read_prepare_sync()", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", " - mac802154: llsec: add skb_cow_data() before in-place crypto", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", " - keys: Pin request_key_auth payload in instantiate paths", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: ath11k: fix warning when unbinding", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", " - bpf: use kvfree() for replaced sysctl write buffer", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", " - fpga: region: fix use-after-free in child_regions_with_firmware()", " - ocfs2: reject oversized group bitmap descriptors", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: fix posix_acl leak on SETACL decode failure", " - nfsd: check get_user() return when reading princhashlen", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", " - mptcp: fix missing wakeups in edge scenarios", " - hv: utils: handle and propagate errors in kvp_register", " - misc: fastrpc: Add dma_mask to fastrpc_channel_ctx", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - fuse: re-lock request before replacing page cache folio", " - ksmbd: reject non-VALID session in compound request branch", " - Documentation: ioctl-number: Extend \"Include File\" column width", " - crypto: qat - Replace kzalloc() + copy_from_user() with memdup_user()", " - crypto: qat - Return pointer directly in adf_ctl_alloc_resources", " - crypto: qat - remove unused character device and IOCTLs", " - Linux 5.15.211", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39931", " - crypto: af_alg - Set merge to zero early in af_alg_sendmsg", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31451", " - ext4: add bounds check for inline data length in ext4_read_inline_page", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43355", " - iio: light: bh1780: fix PM runtime leak on error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53139", " - drm/v3d: Skip CSD when it has zeroed workgroups", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31402", " - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-23364", " - ksmbd: Compare MACs in constant time", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43341", " - net/ipv6: ioam6: prevent schema length wraparound in trace fill", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46208", " - batman-adv: stop tp_meter sessions during mesh teardown", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2023-54271", " - blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed", " before init", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53189", " - mm/huge_memory: update file PMD counter before folio_put()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52918", " - Bluetooth: serialize accept_q access", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46160", " - btrfs: fix missing last_unlink_trans update when removing a directory", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46195", " - smb: client: validate dacloffset before building DACL pointers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46292", " - pmdomain: core: Fix detach procedure for virtual devices in genpd", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46159", " - btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to", " info-leak", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46191", " - fbcon: Avoid OOB font access if console rotation fails", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46116", " - xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46193", " - xfrm: ah: account for ESN high bits in async callbacks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46180", " - wifi: brcmfmac: Fix potential use-after-free issue when stopping", " watchdog task", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31709", " - smb: client: validate the whole DACL before rewriting it in cifsacl", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46196", " - tracepoint: balance regfunc() on func_add() failure in", " tracepoint_add_func()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46291", " - crypto: caam - guard HMAC key hex dumps in hash_digest_key", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46090", " - ALSA: aloop: Fix peer runtime UAF during format-change stop", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46052", " - ceph: only d_add() negative dentries when they are unhashed", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45999", " - erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46103", " - can: ucan: fix devres lifetime", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46056", " - Bluetooth: hci_event: fix potential UAF in SSP passkey handlers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46299", " - hfsplus: fix held lock freed on hfsplus_fill_super()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46169", " - hfsplus: fix uninit-value by validating catalog record size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45991", " - udf: fix partition descriptor append bookkeeping", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46065", " - fbdev: defio: Disconnect deferred I/O from the lifetime of struct", " fb_info", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46086", " - net: bridge: use a stable FDB dst snapshot in RCU readers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46003", " - net: qrtr: ns: Limit the total number of nodes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46038", " - net: qrtr: ns: Free the node during ctrl_cmd_bye()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46026", " - net: qrtr: ns: Limit the maximum number of lookups", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46091", " - media: rc: igorplugusb: heed coherency rules", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46078", " - erofs: fix the out-of-bounds nameoff handling for trailing dirents", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46069", " - wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46021", " - thermal: core: Fix thermal zone governor cleanup issues", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46092", " - wifi: rtw88: check for PCI upstream bridge existence", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31700", " - net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31712", " - ksmbd: require minimum ACE size in smb_check_perm_dacl()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31708", " - smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43350", " - smb: client: require a full NFS mode SID before reading mode bits", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31711", " - smb: server: fix active_num_conn leak on transport allocation failure", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31715", " - f2fs: fix UAF caused by decrementing sbi->nr_pages[] in", " f2fs_write_end_io()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43492", " - lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43383", " - net/tcp-md5: Fix MAC comparison to be constant-time", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52933", " - io_uring/poll: fix signed comparison in io_poll_get_ownership()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-22026", " - nfsd: don't ignore the return code of svc_proc_register()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2023-54125", " - fs/ntfs3: Return error for inconsistent extended attributes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31449", " - ext4: validate p_idx bounds in ext4_ext_correct_indexes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39929", " - smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45852", " - Revert \"RDMA/rxe: Fix double free in rxe_srq_from_init\"", " - RDMA/rxe: Fix double free in rxe_srq_from_init", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39863", " - wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info", " work", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43064", " - dmaengine: idxd: Fix not releasing workqueue on .release()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", " * CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", " * CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", " * CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Set CONFIG_ARM64_ERRATUM_4118414=y", " * CVE-2025-10263", " - arm64: cputype: Add C1-Premium definitions", " - arm64: cputype: Add C1-Ultra definitions", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", " * SAUCE: Revert erroneous application of \"netfilter: nf_tables: fix inverted", " genmask check in nft_map_catchall_activate()\" (LP: #2164800)", " - SAUCE: Revert \"netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()\"", "" ], "package": "linux-kvm", "version": "5.15.0-1109.114", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2165588, 2166457, 1786013, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2163508, 2164699, 1961566, 1956562, 2164516, 2137199, 2165170, 2165170, 2165166, 2165125, 2165125, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2164800 ], "author": "Thibault Ferrante ", "date": "Thu, 10 Sep 2026 15:20:26 +0200" } ], "notes": "linux-kvm-headers-5.15.0-1109 version '5.15.0-1109.114' (source package linux-kvm version '5.15.0-1109.114') was added. linux-kvm-headers-5.15.0-1109 version '5.15.0-1109.114' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1108-kvm. As such we can use the source package version of the removed package, '5.15.0-1108.113', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-5.15.0-1109-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": null }, "to_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1109.114", "version": "5.15.0-1109.114" }, "cves": [ { "cve": "CVE-2026-64582", "url": "https://ubuntu.com/security/CVE-2026-64582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix a use-after-free problem in rxe_mmap rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1: list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */ ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */ [...] rxe_vma_open(vma); /* kref_get, ref → 2 */ remap_vmalloc_range_partial() walks PTEs without any lock. A concurrent DESTROY_CQ ioctl on another CPU calls: kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */ vfree(ip->obj) /* clears vmalloc PTEs mid-walk */ kfree(ip) /* frees rxe_mmap_info */ This yields: 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF. It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get). The call trace are as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:validate_page_before_insert+0x32/0x300 Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5 RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00 R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20 FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0 Call Trace: insert_page+0x8f/0x190 ? __pfx_insert_page+0x10/0x10 ? kasan_save_alloc_info+0x38/0x60 vm_insert_page+0x2e7/0x400 remap_vmalloc_range_partial+0x212/0x3e0 remap_vmalloc_range+0x6e/0xb0 ? __kasan_check_write+0x14/0x30 rxe_mmap+0x2e9/0x5d0 ib_uverbs_mmap+0x1ad/0x2c0 __mmap_region+0x12c2/0x2ad0 ? __pfx___mmap_region+0x10/0x10 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_prev_slot+0x360/0x39c0 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_next_slot+0x1e5b/0x2f40 ? __sanitizer_cov_trace_cmp8+0x18/0x30 ? unmapped_area_topdown+0x4dd/0x610 ? kfree+0x1b1/0x440 ? free_cpumask_var+0x16/0x30 ? __kasan_slab_free+0x7d/0xa0 ? __sanitizer_cov_trace_cmp8+0x18/0x30 mmap_region+0x2e6/0x3c0 do_mmap+0xa3e/0x12a0 ? __pfx_do_mmap+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? down_write_killable+0xba/0x160 ? __pfx_down_write_killable+0x10/0x10 ? __sanitizer_cov_trace_cmp4+0x16/0x30 vm_mmap_pgoff+0x2d4/0x4a0 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x1bf/0x270 ksys_mmap_pgoff+0x40c/0x690 ? __sanitizer_cov_trace_const_cmp4+0x16/0x30 ? __pfx_ksys_mmap_pgoff+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? _raw_spin_trylock+0xbb/0x130 ? __pfx__raw_spin_trylock+0x10/0x10 __x64_sys_mmap+0x135/0x1e0 x64_sys_c ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-05 12:18:00 UTC" }, { "cve": "CVE-2026-74468", "url": "https://ubuntu.com/security/CVE-2026-74468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 (\"gpio: sch: use raw_spinlock_t in the irq startup path\") and commit 90f0109019e6 (\"gpio: eic-sprd: use raw_spinlock_t in the irq startup path\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74482", "url": "https://ubuntu.com/security/CVE-2026-74482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74443", "url": "https://ubuntu.com/security/CVE-2026-74443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at \t(unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74444", "url": "https://ubuntu.com/security/CVE-2026-74444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes \tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74453", "url": "https://ubuntu.com/security/CVE-2026-74453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the \"Auto-initialise Tile State Data Array\" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74455", "url": "https://ubuntu.com/security/CVE-2026-74455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: validate uCAN receive record lengths pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74456", "url": "https://ubuntu.com/security/CVE-2026-74456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 (\"net: usb: lan78xx: Fix double free issue with interrupt buffer allocation\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74457", "url": "https://ubuntu.com/security/CVE-2026-74457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74458", "url": "https://ubuntu.com/security/CVE-2026-74458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74459", "url": "https://ubuntu.com/security/CVE-2026-74459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74460", "url": "https://ubuntu.com/security/CVE-2026-74460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74461", "url": "https://ubuntu.com/security/CVE-2026-74461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74463", "url": "https://ubuntu.com/security/CVE-2026-74463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74464", "url": "https://ubuntu.com/security/CVE-2026-74464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74465", "url": "https://ubuntu.com/security/CVE-2026-74465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the \"hash\" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68451", "url": "https://ubuntu.com/security/CVE-2026-68451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA ECC private key requests cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "high", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68452", "url": "https://ubuntu.com/security/CVE-2026-68452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-74467", "url": "https://ubuntu.com/security/CVE-2026-74467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Check CAP_NET_ADMIN for private ioctls Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74469", "url": "https://ubuntu.com/security/CVE-2026-74469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74471", "url": "https://ubuntu.com/security/CVE-2026-74471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Check return value of __register_event() in trace_module_add_events() trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74473", "url": "https://ubuntu.com/security/CVE-2026-74473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74475", "url": "https://ubuntu.com/security/CVE-2026-74475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74478", "url": "https://ubuntu.com/security/CVE-2026-74478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: vector: fix use-after-free in vector_mmsg_rx() When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: \tif (header_check < 0) { \t\tdev_kfree_skb_irq(skb); \t\tvp->estats.rx_encaps_errors++; \t\tcontinue; \t} The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: \t(*skbuff_vector) = NULL; \tmmsg_vector++; \tskbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74480", "url": "https://ubuntu.com/security/CVE-2026-74480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74481", "url": "https://ubuntu.com/security/CVE-2026-74481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74485", "url": "https://ubuntu.com/security/CVE-2026-74485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: reject a flag character as the field delimiter The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: \tmemset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering \tPaPEPPxPPiP with 'P' as the delimiter (name \"a\", type extension, magic \"x\", interpreter \"i\", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74488", "url": "https://ubuntu.com/security/CVE-2026-74488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: \trx_skb = __skb_dequeue(&list); \trx_hdr = (struct rx_packet_hdr *)rx_skb->data; \tif (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && \t ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { \t\tmwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, \t\t\t\t\t\t skb->len); \t} The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with \tif (!reuse_skb) \t\tdev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes \ties_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, \tfor (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { \t\tu8 ie_len = pos[1]; \t\tif (pos + 2 + ie_len > end) \t\t\tbreak; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74490", "url": "https://ubuntu.com/security/CVE-2026-74490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74492", "url": "https://ubuntu.com/security/CVE-2026-74492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: do not update comments from kernel-side hash adds mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74493", "url": "https://ubuntu.com/security/CVE-2026-74493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket use-after-free during link group termination __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74495", "url": "https://ubuntu.com/security/CVE-2026-74495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74497", "url": "https://ubuntu.com/security/CVE-2026-74497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74498", "url": "https://ubuntu.com/security/CVE-2026-74498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74499", "url": "https://ubuntu.com/security/CVE-2026-74499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() snd_usbmidi_akai_output() computes its fill-loop bound \tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74505", "url": "https://ubuntu.com/security/CVE-2026-74505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74507", "url": "https://ubuntu.com/security/CVE-2026-74507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74508", "url": "https://ubuntu.com/security/CVE-2026-74508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74512", "url": "https://ubuntu.com/security/CVE-2026-74512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74518", "url": "https://ubuntu.com/security/CVE-2026-74518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocate_file_region_entries() allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74519", "url": "https://ubuntu.com/security/CVE-2026-74519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-74523", "url": "https://ubuntu.com/security/CVE-2026-74523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74525", "url": "https://ubuntu.com/security/CVE-2026-74525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: free TX rings on RX allocation failure When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74540", "url": "https://ubuntu.com/security/CVE-2026-74540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74546", "url": "https://ubuntu.com/security/CVE-2026-74546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74547", "url": "https://ubuntu.com/security/CVE-2026-74547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74548", "url": "https://ubuntu.com/security/CVE-2026-74548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix UAF of txrx_stats in nv_remove nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74549", "url": "https://ubuntu.com/security/CVE-2026-74549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74556", "url": "https://ubuntu.com/security/CVE-2026-74556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74557", "url": "https://ubuntu.com/security/CVE-2026-74557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: \tsenselen = get_unaligned_be16(data); \tif (datalen < senselen) \t\tgoto invalid_datalen; \tmemcpy(sc->sense_buffer, data + 2, \t min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74563", "url": "https://ubuntu.com/security/CVE-2026-74563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74579", "url": "https://ubuntu.com/security/CVE-2026-74579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes.", "cve_priority": "medium", "cve_public_date": "2026-08-17 06:19:00 UTC" }, { "cve": "CVE-2026-74564", "url": "https://ubuntu.com/security/CVE-2026-74564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74566", "url": "https://ubuntu.com/security/CVE-2026-74566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: make keyring key-chunk byte order agree with keyring_diff_objects() keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74567", "url": "https://ubuntu.com/security/CVE-2026-74567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74569", "url": "https://ubuntu.com/security/CVE-2026-74569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and \"datalen = datalen + diff - msglen\" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-43491", "url": "https://ubuntu.com/security/CVE-2026-43491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-74577", "url": "https://ubuntu.com/security/CVE-2026-74577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: \tr = nlmsg_data(nlh); \tr->rtm_family\t = AF_MPLS; \tr->rtm_dst_len\t= 20; \tr->rtm_src_len\t= 0; \tr->rtm_table\t= RT_TABLE_MAIN; \tr->rtm_type\t= RTN_UNICAST; \tr->rtm_scope\t= RT_SCOPE_UNIVERSE; \tr->rtm_protocol = rt->rt_protocol; \tr->rtm_flags\t= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64543", "url": "https://ubuntu.com/security/CVE-2026-64543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix use-after-free of the discoverer in tipc_disc_rcv() bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(), but tipc_disc_rcv() still dereferences b->disc in RX softirq under rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv). L2 bearers are safe thanks to the synchronize_net() in tipc_disable_l2_media(), but the UDP bearer defers that call to the cleanup_bearer() workqueue, so the discoverer is freed with no grace period: BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149) Read of size 8 at addr ffff88802348b728 by task poc_tipc/184 tipc_disc_rcv (net/tipc/discover.c:149) tipc_rcv (net/tipc/node.c:2126) tipc_udp_recv (net/tipc/udp_media.c:391) udp_rcv (net/ipv4/udp.c:2643) ip_local_deliver_finish (net/ipv4/ip_input.c:241) Freed by task 181: kfree (mm/slub.c:6565) bearer_disable (net/tipc/bearer.c:418) tipc_nl_bearer_disable (net/tipc/bearer.c:1001) The bearer is freed with kfree_rcu(); free the discoverer the same way. Add an rcu_head to struct tipc_discoverer and free it and its skb from an RCU callback. Because the RCU callback (tipc_disc_free_rcu) lives in module text, a call_rcu() that is still pending when the tipc module is unloaded would invoke a freed function. Add an rcu_barrier() to tipc_exit() after the bearer subsystem has been torn down, so all pending discoverer callbacks have run before the module text goes away. Reachable from an unprivileged user namespace: the TIPCv2 genl family is netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC and CONFIG_TIPC_MEDIA_UDP.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72123", "url": "https://ubuntu.com/security/CVE-2026-72123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 (\"can: bcm: use call_rcu() instead of costly synchronize_rcu()\") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a \"scheduling while atomic\" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72019", "url": "https://ubuntu.com/security/CVE-2026-72019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d (\"macvlan: do not assume mac_header is set in macvlan_broadcast()\") for exactly this purpose.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-52977", "url": "https://ubuntu.com/security/CVE-2026-52977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-72282", "url": "https://ubuntu.com/security/CVE-2026-72282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72068", "url": "https://ubuntu.com/security/CVE-2026-72068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64301", "url": "https://ubuntu.com/security/CVE-2026-64301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error path where process_scmi_regulator_of_node() fails, the function returns without calling of_node_put() on the child node, leaking the reference. Add of_node_put(np) on the error path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64304", "url": "https://ubuntu.com/security/CVE-2026-64304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - validate RSA CRT component lengths The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64593", "url": "https://ubuntu.com/security/CVE-2026-64593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not trim a device which is not writeable [BUG] There is a bug report that btrfs/242 can randomly fail with the following NULL pointer dereference: run fstests btrfs/242 at 2026-06-01 10:25:08 BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609) BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874 BTRFS info (device sdc): using crc32c checksum algorithm BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS info (device sdc): allowing degraded mounts BTRFS info (device sdc): turning on async discard BTRFS info (device sdc): enabling free space tree Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000 CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_trim_fs+0x34c/0xa00 [btrfs] lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs] Call trace: btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P) btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] __arm64_sys_ioctl+0xac/0x108 invoke_syscall.constprop.0+0x5c/0xd0 el0_svc_common.constprop.0+0x40/0xf0 do_el0_svc+0x24/0x40 el0_svc+0x40/0x1d0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00) ---[ end trace 0000000000000000 ]--- Also the reporter is very kind to test the following ASSERT() added to btrfs_trim_free_extents_throttle(): \tASSERT(device->bdev, \t \"devid=%llu path=%s dev_state=0x%lx\\n\", \t device->devid, btrfs_dev_name(device), device->dev_state); And it shows the following output: assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82) Which means the device->bdev is NULL, and the dev_state is BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without BTRFS_DEV_STATE_WRITEABLE flag set. [CAUSE] The pc points to the following call chain: btrfs_trim_fs() |- btrfs_trim_free_extents() |- btrfs_trim_free_extents_throttle() |- bdev_max_discard_sectors(device->bdev) So the NULL pointer dereference is caused by device->bdev being NULL. This looks impossible by a quick glance, as just before calling btrfs_trim_free_extents_throttle(), we have skipped any device that has BTRFS_DEV_STATE_MISSING flag set. However in this particular case, there is a window where the missing device is later re-scanned, causing btrfs to remove the BTRFS_DEV_STATE_MISSING flag: btrfs_control_ioctl() |- btrfs_scan_one_device() |- device_list_add() |- rcu_assign_pointer(device->name, name); | This updates the missing device's path to the new good path. | |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state) This removes the BTRFS_DEV_STATE_MISSING flag. This allows the missing device to re-appear and clear the BTRFS_DEV_STATE_MISSING flag. However the device still does not have the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated. The bdev pointer remains NULL, triggering the crash later. [FIX] This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and device->bdev pointer, and shows a gap in btrfs's re-appearing-device handling. The proper handling of re-appearing device will need quite some extra work, which is out of the context of this small ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64594", "url": "https://ubuntu.com/security/CVE-2026-64594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: initialize reset_work at allocation time ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on ffs->reset_work when a functionfs instance is unmounted: \tffs_data_reset(ffs); \tcancel_work_sync(&ffs->reset_work); However ffs->reset_work is only ever initialized via INIT_WORK() in ffs_func_set_alt() and ffs_func_disable(), and only on the FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed() when the instance is mounted with the \"no_disconnect\" option, so for the common case (no \"no_disconnect\", or mounted and unmounted without ever being deactivated) reset_work is never initialized. ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch it either, so reset_work.func is left NULL. cancel_work_sync() on such a work then trips the WARN_ON(!work->func) guard in __flush_work(): WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flush_work cancel_work_sync ffs_fs_kill_sb [usb_f_fs] deactivate_locked_super deactivate_super cleanup_mnt __cleanup_mnt task_work_run exit_to_user_mode_loop el0_svc On older kernels cancel_work_sync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization. Initialize reset_work once in ffs_data_new() so it is always valid for the lifetime of the ffs_data, and drop the now-redundant INIT_WORK() calls from the two deactivation paths.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68456", "url": "https://ubuntu.com/security/CVE-2026-68456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect() ueagle-atm uses the asynchronous request_firmware_nowait() in .probe(), but does not wait for its completion, not even in .disconnect(); so, if the device is unplugged meanwhile, its teardown runs concurrently with that. Even though this inconsistency is worth addressing on its own, it has also triggered several bug reports in syzbot over the years (some auto-closed) where the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER) creates a firmware subdirectory in the device directory during its removal, which might hit unexpected conditions in kernfs, apparently, depending at which point the add and remove operations raced. (See links.) The pattern is: usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2 usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw Call trace: ... kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs _request_firmware request_firmware_work_func ... (Some variations are observed, after fw_load_sysfs_fallback(), e.g., [1].) While the kernfs side is being looked at, the ueagle-atm side can be fixed by waiting for the pre-firmware load in the .disconnect() handler. This change has a similar approach to previous work by Andrey Tsygunka [2] (wait_for_completion() in .disconnect()), but it is relatively different in design/implementation; using the Originally-by tag for credit assignment. This has been tested with: - synthetic reproducer to check the error path; - USB gadget (virtual device) to check the firmware upload path; - QEMU device emulator to check the device ID re-enumeration path; (The latter two were written by Claude; no other code/text in this commit.) Links (year first reported): 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd4 2024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84d86f0d71394829df6fc53daf6642c045983881 2021 https://syzbot.org/bug?id=3302dc1c0e2b9c94f2e8edb404eabc9267bc6f90 [1] https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 [2] https://lore.kernel.org/lkml/20250410093146.3776801-2-aitsygunka@yandex.ru/", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-64329", "url": "https://ubuntu.com/security/CVE-2026-64329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled. The probe error path already orders free_irq() before ucsi_destroy(). This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64352", "url": "https://ubuntu.com/security/CVE-2026-64352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to \"c || rcu_read_lock_held()\", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64355", "url": "https://ubuntu.com/security/CVE-2026-64355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject fragmented frames in devmap Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64361", "url": "https://ubuntu.com/security/CVE-2026-64361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length check_and_correct_requested_length() compares (off + len) against node_size using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfs_brec_remove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail. For example, with off=14 and len=0xFFFFFFF2 (underflowed from data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6, which is less than a typical node_size of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer. Fix this by widening the addition to u64 before comparing against node_size. This prevents the u32 wrap while keeping the logic straightforward.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64363", "url": "https://ubuntu.com/security/CVE-2026-64363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: appleir: fix UAF on pending key_up_timer in remove() appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 (\"HID: appletb-kbd: fix UAF in inactivity-timer cleanup path\") and has been present since the driver was introduced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64371", "url": "https://ubuntu.com/security/CVE-2026-64371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (part 1) Fix the easy cases where procfs currently calls ptrace_may_access() without exec_update_lock protection, where the fix is to simply add the extra lock or use mm_access(): - do_task_stat(): grab exec_update_lock - proc_pid_wchan(): grab exec_update_lock - proc_map_files_lookup(): use mm_access() instead of get_task_mm() - proc_map_files_readdir(): use mm_access() instead of get_task_mm() - proc_ns_get_link(): grab exec_update_lock - proc_ns_readlink(): grab exec_update_lock", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64364", "url": "https://ubuntu.com/security/CVE-2026-64364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix out-of-bounds bit access on mt_io_flags mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG. As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs \tfor (i = 0; i < mt->num_slots; i++) \t\tclear_bit(i, &td->mt_io_flags); with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received). The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required. Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two \"mt_io_flags & MT_IO_SLOTS_MASK\" arming checks become bitmap_empty(td->active_slots, td->maxcontacts). Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64375", "url": "https://ubuntu.com/security/CVE-2026-64375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (FD links) proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways. To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link().", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64390", "url": "https://ubuntu.com/security/CVE-2026-64390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: track the connection owning a byte-range lock SMB2_LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llist_lock. With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbd_lock and struct file_lock objects. Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llist_lock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-31610", "url": "https://ubuntu.com/security/CVE-2026-31610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: \tif (conn->use_spnego && conn->mechToken) { \t\tkfree(conn->mechToken); \t\tconn->mechToken = NULL; \t} so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-64380", "url": "https://ubuntu.com/security/CVE-2026-64380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: harden POSIX SID length parsing posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64379", "url": "https://ubuntu.com/security/CVE-2026-64379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: mask server-provided mode to 07777 in modefromsid When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64401", "url": "https://ubuntu.com/security/CVE-2026-64401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: resolve SWN tcon from live registrations cifs_swn_notify() looks up a witness registration by id under cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifs_get_swn_reg() lets multiple tcons for the same net/share name share one registration id. A same-share second mount can keep the cifs_swn_reg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tc_lock or incrementing tc_count through swnreg->tcon only moves the use-after-free earlier. Taking tc_lock while holding cifs_swnreg_idr_mutex also violates the documented CIFS lock order. Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifs_tcp_ses_lock -> tc_lock order. The notification path uses that pinned tcon directly and drops the reference when done. Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifs_swn_unregister() while the registration is still protected by cifs_swnreg_idr_mutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings. This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENT_MOVE ordering for the representative tcon because the old-IP unregister is sent before cifs_swn_register() sends the new-IP register.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64381", "url": "https://ubuntu.com/security/CVE-2026-64381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix next buffer leak in receive_encrypted_standard() receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64206", "url": "https://ubuntu.com/security/CVE-2026-64206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64413", "url": "https://ubuntu.com/security/CVE-2026-64413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: zero chainstack array sashiko reports: looking at ebtables table translation, could a sparse cpu_possible_mask lead to an uninitialized pointer free? If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1]. Not a real-world bug, such allocation isn't expected to fail in the first place.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64428", "url": "https://ubuntu.com/security/CVE-2026-64428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: sch: use raw_spinlock_t in the irq startup path sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64438", "url": "https://ubuntu.com/security/CVE-2026-64438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix VF2PF work teardown race in adf_disable_sriov() The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adf_accel_vf_info). Currently, adf_disable_sriov() destroys per-VF mutexes and frees vf_info without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory. This manifests as a use-after-free when KASAN is enabled: BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] Call Trace: kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vf_info is destroyed. Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64441", "url": "https://ubuntu.com/security/CVE-2026-64441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr() Three IE/attribute parsing functions have missing bounds checks. rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtw_get_sec_ie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain. rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at entry, before verifying that wps_ielen is large enough to contain the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside the attribute loop, get_unaligned_be16() is called on attr_ptr and attr_ptr+2 without checking that 4 bytes remain in the buffer. Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie() and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum IE length requirement, add a wps_ielen < 6 early return in rtw_get_wps_attr(), and add a 4-byte bounds check in its inner loop.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64461", "url": "https://ubuntu.com/security/CVE-2026-64461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64446", "url": "https://ubuntu.com/security/CVE-2026-64446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie() supplicant_ie is a 256-byte array in struct security_priv. The WPA and WPA2 IE copy paths use: memcpy(padapter->securitypriv.supplicant_ie, &pwpa[0], wpa_ielen + 2); where wpa_ielen is the raw IE length field (u8, 0-255). When a local user supplies a connect request via nl80211 with a crafted WPA IE of length 255, wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into the adjacent last_mic_err_time field. rtw_parse_wpa_ie() does not prevent this: its length consistency check compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255 when wpa_ie_len = 257, so the check passes silently. Add explicit bounds checks for both the WPA and WPA2 paths before the memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the supplicant_ie buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64448", "url": "https://ubuntu.com/security/CVE-2026-64448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: restrict implied bcc[0] exemption to responses without data area smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received (\"server can return one byte more due to implied bcc[0]\"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, yet smb2_check_message() still accepts it. The subsequent decoder then reads past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server; both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders are affected: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00 Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81 CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 asn1_ber_decoder+0x16a7/0x1b00 decode_negTokenInit+0x19/0x30 SMB2_negotiate+0x31d9/0x4c90 cifs_negotiate_protocol+0x1f2/0x3f0 cifs_get_smb_ses+0x93f/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 85: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 0 bytes to the right of allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0) which belongs to the cache cifs_small_rq of size 448 BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50 Read of size 329 at addr ffff88800726c678 by task mount.cifs/89 CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x36/0x50 decode_ntlmssp_challenge+0x457/0x680 SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0 SMB2_sess_setup+0x219/0x4f0 cifs_setup_session+0x248/0xaf0 cifs_get_smb_ses+0xf79/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 93: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 120 bytes inside of allocated 448-byte region [ffff88800726c600, ffff88800726c7c0) which belongs to the cache cifs_small_rq of size 448 Restrict the +1 exemption to responses that have no data area, so that it still covers the bcc[0] omission it was meant for. When a data area is present, the +1 discrepancy instead means the reported data length overruns the ---truncated---", "cve_priority": "negligible", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64462", "url": "https://ubuntu.com/security/CVE-2026-64462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64475", "url": "https://ubuntu.com/security/CVE-2026-64475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Release the VGA arbiter client on register_device() failure The re-order in the Fixes commit below displaced vfio_pci_vga_init() as the last failure point of what is now vfio_pci_core_register_device() without introducing an unwind for the VGA arbiter registration. In current kernels this is mostly benign because vfio_pci_set_decode() only uses pci_dev state, but the original failure path could leave a callback with a freed vdev cookie. The stale registration also becomes unsafe again once the callback follows drvdata to the vfio device. Add the required VGA unwind callout.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64488", "url": "https://ubuntu.com/security/CVE-2026-64488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return early if any fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64510", "url": "https://ubuntu.com/security/CVE-2026-64510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64512", "url": "https://ubuntu.com/security/CVE-2026-64512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Suppress UBSAN warning caused by field misuse The definition of reg->access_width changes depending on the reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses access_width to indicate the PCC region, which can result in a UBSAN if the value is greater than 4. For example: UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9 shift exponent 32 is too large for 32-bit type 'int' CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy) Hardware name: To be filled by O.E.M. Call trace: ...(trimming) ubsan_epilogue+0x10/0x48 __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ... (trimming) Lets fix this by validating the region type, as well as whether access_width has a value. Then since we are returning bit_width directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting the size.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68466", "url": "https://ubuntu.com/security/CVE-2026-68466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68467", "url": "https://ubuntu.com/security/CVE-2026-68467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mchp23k256: use SPI match data for chip caps The driver stores chip capacity information in both the OF match table and the SPI id table. Probe currently uses of_device_get_match_data(), so a non-OF SPI modalias match falls back to mchp23k256_caps even when the SPI id table selected a different part. Use spi_get_device_match_data() so SPI id-table driver_data is consumed when OF match data is absent. This keeps the existing default fallback while avoiding the wrong MTD geometry for id-table-only matches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68469", "url": "https://ubuntu.com/security/CVE-2026-68469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix permanently busy scans after multiple roam iterations In order for the firmware to sleep, the driver has to confirm a previously received sleep request. The normal sequence of evets goes like this: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Before sending the sleep-confirm command, the driver must make sure there are no commands either running or waiting to be completed. mwifiex_ret_802_11_associate() unconditionally sets ps_state = PS_STATE_AWAKE when it processes the association command response, outside of the normal powersave management flow. If EVENT_SLEEP arrives while the association command is in flight, ps_state is PRE_SLEEP when the association command response is parsed, and the forced AWAKE overwrites it. The deferred sleep-confirm is never sent. A subsequent scan_start command is correctly acknowledged, but the firmware doesn't generate scan_result events. The scan request never finishes, and additional requests from userspace fail with -EBUSY. After testing on both IW412 and W8997, I could only trigger the bug on the IW412 and observed the firmwares behave differently. On the IW412 the firmware still sends EVENT_SLEEP while the authentication / association process is ongoing. A W8997 under the same conditions seems to suppress power-save for the duration of the association, so PRE_SLEEP never coincided with the association response even after extended periods of testing using the loops described below (>12hours). On the IW412, the delay between commands that triggers an EVENT_SLEEP was empirically determined to be ~20ms. This delay can naturally occur when the driver is outputting debugging information (debug_mask = 0x00000037), in which situation the busy scans issue is repeatable while running \"test 1)\" as described below. If the delay between commands is less than ~20ms, the firmware stays awake and the issue was not reproducible running the same test. The host_mlme=false path also behaves differently. In this case, the entire authentication / association transaction is executed by one command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit EVENT_SLEEP while the command is running. Remove the assignment so the ps_state is only manipulated in the paths that are related to powersave event handling and on the main workqueue for correct sleep confirmation. The following loop tests were performed (with debugging output enabled): 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations. Each test ran in each device for at least 3 hours.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68474", "url": "https://ubuntu.com/security/CVE-2026-68474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access() spufs_mem_mmap_access() computes the local store offset as address - vma->vm_start, but bounds-checks it against vma->vm_end instead of the local store size. On 64-bit, offset is always well below vma->vm_end, so the clamp never fires and len stays unbounded against the LS_SIZE buffer returned by ctx->ops->get_ls(). Reject offsets at or beyond LS_SIZE and clamp len to the remaining space, mirroring the guard already used by spufs_mem_mmap_fault() and spufs_ps_fault().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68475", "url": "https://ubuntu.com/security/CVE-2026-68475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: reset: sunxi: fix memory region leak on ioremap failure In sunxi_reset_init(), when ioremap() fails, the memory region obtained via request_mem_region() is not released, leading to a resource leak. Add an err_mem_region label to properly release the memory region before freeing the data structure.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68478", "url": "https://ubuntu.com/security/CVE-2026-68478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memstick: ms_block: reject a card that reports too many blocks msb_ftl_initialize() computes the zone count from the card block count with no bound: \tmsb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; \t... \tfor (i = 0; i < msb->zone_count; i++) \t\tmsb->free_block_count[i] = MS_BLOCKS_IN_ZONE; msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the init loop past the end too. A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68479", "url": "https://ubuntu.com/security/CVE-2026-68479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: validate firmware patch bounds rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup. The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72004", "url": "https://ubuntu.com/security/CVE-2026-72004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix memory leak in ieee80211_register_hw() If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl. Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72005", "url": "https://ubuntu.com/security/CVE-2026-72005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: avoid full teardown before work setup in probe rt2x00lib_probe_dev() uses the full rt2x00lib_remove_dev() teardown for all probe failures. However, drv_data allocation and workqueue allocation can fail before intf_work, autowakeup_work and sleep_work have been initialized. Do not enter the full remove path until the probe has reached the point where those work items are set up. Return directly for drv_data allocation failure, and use a small early cleanup path for workqueue allocation failure. This issue was found by our static analysis tool and then confirmed by manual review of rt2x00lib_probe_dev() and rt2x00lib_remove_dev(). The early probe exits should not call a common teardown path that assumes the later work setup has already completed. A QEMU PoC forced alloc_ordered_workqueue() to fail before the work initializers are reached. The resulting fail path entered rt2x00lib_remove_dev(), and DEBUG_OBJECTS reported invalid work drains with rt2x00lib_probe_dev() and rt2x00lib_remove_dev() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72010", "url": "https://ubuntu.com/security/CVE-2026-72010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72013", "url": "https://ubuntu.com/security/CVE-2026-72013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent NULL pointer dereference in machine_kexec_prepare() A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72021", "url": "https://ubuntu.com/security/CVE-2026-72021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in SCTP state lookup set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header. This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed. Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72022", "url": "https://ubuntu.com/security/CVE-2026-72022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: llc: fix SAP refcount leak in llc_ui_autobind() llc_ui_autobind() opens a SAP after choosing a dynamic LSAP. llc_sap_open() returns a reference owned by the caller, and llc_sap_add_socket() takes a second reference for the socket's membership in the SAP hash tables. llc_ui_bind() drops the caller's reference after adding the socket, but llc_ui_autobind() keeps it. When the socket is closed, llc_sap_remove_socket() releases only the socket reference, leaving the SAP on llc_sap_list with sk_count == 0. This is user-visible because repeated autobind and close cycles can consume all dynamic SAP values and make later autobinds fail with -EUSERS. Drop the caller's reference after a successful autobind, matching llc_ui_bind()'s ownership model.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72024", "url": "https://ubuntu.com/security/CVE-2026-72024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: remove interfaces with RCU list deletion Queue wake, stop, and disable paths walk local->interfaces under RCU. The bulk hardware teardown path removes entries with list_del(), so an asynchronous transmit completion can follow a poisoned list node in ieee802154_wake_queue(). Use list_del_rcu() as in the single-interface removal path. The following unregister_netdevice() waits for in-flight RCU readers before freeing the netdevice, so no separate grace-period wait is needed.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72025", "url": "https://ubuntu.com/security/CVE-2026-72025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/monwriter: Reject buffer reuse with different data length When data buffers are reused, e.g. for interval sample records, the first record determines the data length, and the size of the buffer for user copy. Current monwriter code does not check if the data length was changed for subsequent records, which also would never happen for valid user programs. However, a malicious user could change the data length, resulting in out of bounds user copy to the kernel buffer, and memory corruption. By default, the monwriter misc device is created with root-only permissions, so practical impact is typically low. Fix this by checking for changed data length and rejecting such records.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72036", "url": "https://ubuntu.com/security/CVE-2026-72036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked multiq_dequeue() takes a packet from a band's child with a direct ->dequeue() call after multiq_peek() peeked it. When the child is non-work-conserving the peek stashes the skb in the child's gso_skb, so the direct dequeue returns a different skb and orphans the stash, desyncing the child's qlen/backlog. With a qfq child reached through a peeking parent (e.g. tbf) this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_prio already does and as sch_red and sch_sfb were just fixed to do. The helper is a no-op when the child has no stash, so a work-conserving child is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72038", "url": "https://ubuntu.com/security/CVE-2026-72038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: fix BAR resource leak on PF number failure If cn23xx_get_pf_num() fails, the function returns without unmapping either BAR. Unmap both BARs before returning from the error path. Found by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72039", "url": "https://ubuntu.com/security/CVE-2026-72039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72229", "url": "https://ubuntu.com/security/CVE-2026-72229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: clean untagged VLAN on netdev registration failure When an mesh interface is registered, it creates an untagged struct batadv_meshif_vlan on top of it via the NETDEV_REGISTER notifier. But in this process, another receiver of this notification can veto the registration. The netdev registration will be aborted because of this veto. The register_netdevice() call will try to clean up the net_device using unregister_netdevice_queue() - which only uses the .priv_destructor to free private resources. In this situation, .dellink will not be called. The cleanup of the untagged batadv_meshif_vlan must thefore be done in the destructor to avoid a leak of this object.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72232", "url": "https://ubuntu.com/security/CVE-2026-72232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: ensure minimal ethernet header on TX As documented in commit 8bd67ebb50c0 (\"net: bridge: xmit: make sure we have at least eth header len bytes\"), it is possible by for a local user with eBPF TC hook access to attach a tc filter which truncates the packet and redirects to an batadv interface. But the code assumes that at least ETH_HLEN bytes are available and thus might read outside of the available buffer. The batadv_interface_tx() must therefore always check itself if enough data is available for the ethernet header and don't rely on min_header_len.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72235", "url": "https://ubuntu.com/security/CVE-2026-72235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: retrieve ethhdr after potential skb realloc on RX pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72047", "url": "https://ubuntu.com/security/CVE-2026-72047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72048", "url": "https://ubuntu.com/security/CVE-2026-72048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix cas_ctl leak on spi_async failure ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72049", "url": "https://ubuntu.com/security/CVE-2026-72049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: admin-gate legacy LLSEC dump operations In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM. Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the \"802.15.4 MAC\" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames. Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family. Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry \"can be retrieved by unprivileged users\" annotations).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72052", "url": "https://ubuntu.com/security/CVE-2026-72052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72054", "url": "https://ubuntu.com/security/CVE-2026-72054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72055", "url": "https://ubuntu.com/security/CVE-2026-72055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink vti6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72056", "url": "https://ubuntu.com/security/CVE-2026-72056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ena: clean up XDP TX queues when regular TX setup fails create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72061", "url": "https://ubuntu.com/security/CVE-2026-72061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sit: require CAP_NET_ADMIN in the device netns for changelink ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72066", "url": "https://ubuntu.com/security/CVE-2026-72066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Bound hotplug states sysfs output states_show() adds CPU hotplug state names into a single sysfs buffer using sprintf(). With enough registered states, this can write past the end of the PAGE_SIZE buffer. Use sysfs_emit_at() so output is bounded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72067", "url": "https://ubuntu.com/security/CVE-2026-72067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Preserve per instance callback errors cpuhp_invoke_callback() unwinds earlier callbacks for the same hotplug state when one instance fails. The rollback path currently reuses ret, so a successful rollback can hide the original error and make the failed transition look successful. Keep the rollback result separate from the original error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72074", "url": "https://ubuntu.com/security/CVE-2026-72074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix type confusion in CDC union descriptor parsing The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72076", "url": "https://ubuntu.com/security/CVE-2026-72076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72078", "url": "https://ubuntu.com/security/CVE-2026-72078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - validate control endpoint type The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72079", "url": "https://ubuntu.com/security/CVE-2026-72079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix use-after-free and double-free in disconnect ims_pcu_disconnect() only intended to perform cleanup when the primary (control) interface is unbound. However, it currently relies on the interface class to distinguish between control and data interfaces. A malicious device could present a data interface with the same class as the control interface, leading to premature cleanup and potential use-after-free or double-free. Switch to verifying that the interface being disconnected is indeed the control interface.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72081", "url": "https://ubuntu.com/security/CVE-2026-72081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix I/O leak on unsupported additional CDB efct_dispatch_fcp_cmd() allocates an efct_io before dispatching an unsolicited FCP command. If the command has an unsupported additional CDB, the function returns -EIO before handing the IO to the SCSI layer. Free the allocated IO before returning from this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72082", "url": "https://ubuntu.com/security/CVE-2026-72082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix refcount leak in efct_hw_io_abort() When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object. Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery. Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72086", "url": "https://ubuntu.com/security/CVE-2026-72086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free the command tag on the TMR submit-failure path scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag. Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails. transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req. Use the same helper, which returns just the tag, on this path too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72088", "url": "https://ubuntu.com/security/CVE-2026-72088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72102", "url": "https://ubuntu.com/security/CVE-2026-72102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm_early_create: fix freeing used table on dm_resume failure If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72105", "url": "https://ubuntu.com/security/CVE-2026-72105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-log: fix a bitset_size overflow on 32bit machines Commit c20e36b7631d (\"dm log: fix out-of-bounds write due to region_count overflow\") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72107", "url": "https://ubuntu.com/security/CVE-2026-72107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix out-of-bounds memory access for non-zero start sector dm-era tracks writes in target-relative blocks, but era_map() calculates the writeset block before applying the target offset. Tables with a non-zero start sector can therefore pass an absolute mapped-device block to metadata_current_marked(). If the absolute block is beyond the current writeset size, writeset_marked() tests past the end of the in-core bitset. KASAN reports this as a vmalloc-out-of-bounds access. Apply the target offset before calculating the era block so writeset lookups use the target-relative block number.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72108", "url": "https://ubuntu.com/security/CVE-2026-72108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm thin metadata: fix metadata snapshot consistency on commit failure __reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata. Reproducer 1: __reserve_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 112 linear /dev/sdc 0 112 3984 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency. dmsetup message tpool 0 \"reserve_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0. Reproducer 2: __release_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 128 linear /dev/sdc 0 128 3968 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata. dmsetup message tpool 0 \"reserve_metadata_snap\" dmsetup message tpool 0 \"release_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked. Fix by deferring the held_root update to commit time. Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72109", "url": "https://ubuntu.com/security/CVE-2026-72109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sparx5: unregister blocking notifier on init failure sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72120", "url": "https://ubuntu.com/security/CVE-2026-72120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu list annotations and operations sashiko-bot remarked the missing use of list_add_rcu() in bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure when bcm_proc_show() traverses the bcm_op's under rcu_read_lock(). To cover all initial settings of the bcm_op's the list_add_rcu() calls are moved to the end of the setup code. While at it, also fix the mirroring removal side: bcm_release() called bcm_remove_op() - which frees the op via call_rcu() - on ops that were still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first. Unlink each op with list_del_rcu() before handing it to bcm_remove_op(), matching the existing pattern in bcm_delete_tx_op()/bcm_delete_rx_op().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72122", "url": "https://ubuntu.com/security/CVE-2026-72122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all mutate both fields under that same lock. Because the lockless reads and the locked writes are unordered with respect to each other, a racing bcm_notify() (device unregister) or bcm_connect() (concurrent bind on another thread sharing the socket) can make bcm_sendmsg() observe an inconsistent combination, e.g. a stale bound=1 together with the now-cleared ifindex=0, silently turning a socket bound to a specific CAN interface into one that also matches \"any\" interface. Keep the lockless bo->bound check purely as a fast-path reject, and move the ifindex read (and a bo->bound re-check) into the locked section, where every writer already serializes. This removes the possibility of observing the two fields torn against each other, rather than trying to fix it with more READ_ONCE()/WRITE_ONCE() pairs on two independently updated fields. Annotate the now-purely-lockless bo->bound accesses consistently across all its write sites. Also fix bcm_rx_setup() silently returning success when the target device disappears concurrently instead of reporting -ENODEV, so a broken RX op is no longer left registered as if it had succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72126", "url": "https://ubuntu.com/security/CVE-2026-72126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72133", "url": "https://ubuntu.com/security/CVE-2026-72133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: Fix completion initialization order before devm_request_irq() The driver calls devm_request_irq() before initializing the completion used by the interrupt handler. Because the interrupt may occur immediately after devm_request_irq(), the handler may execute before init_completion(). This may result in calling complete() on an uninitialized completion, causing undefined behavior. This has been observed with KASAN. Fix this by initializing the completion before registering the IRQ.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72135", "url": "https://ubuntu.com/security/CVE-2026-72135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Make the TPM character devices non-seekable The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset(). Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale. Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged. Tested on Linux 6.12 with KASAN and a swtpm TPM2 device: - sequential partial reads returned the complete response - pread() and preadv() with offset 0x1400 returned -ESPIPE - pwrite() and pwritev() with offset zero returned -ESPIPE - the pending response remained intact after the rejected operations - a subsequent normal command/response cycle completed normally - no KASAN report was produced.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72136", "url": "https://ubuntu.com/security/CVE-2026-72136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72138", "url": "https://ubuntu.com/security/CVE-2026-72138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Fix these issues by properly handling all error cases.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72140", "url": "https://ubuntu.com/security/CVE-2026-72140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource() If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72153", "url": "https://ubuntu.com/security/CVE-2026-72153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72159", "url": "https://ubuntu.com/security/CVE-2026-72159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72160", "url": "https://ubuntu.com/security/CVE-2026-72160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series \"ocfs2: harden inode validators against forged metadata\", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72163", "url": "https://ubuntu.com/security/CVE-2026-72163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72164", "url": "https://ubuntu.com/security/CVE-2026-72164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: avoid moving extents to occupied clusters For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group. The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated. When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run. Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72165", "url": "https://ubuntu.com/security/CVE-2026-72165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: fix condition in 'nand_select_target()' 'cs' here must be in range [0:nanddev_ntargets[.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72166", "url": "https://ubuntu.com/security/CVE-2026-72166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: \terr = io_wait_event_killable(req->wq, ...) \t/* SIGKILL wakes the task, returns -ERESTARTSYS */ \tif (err == -ERESTARTSYS && c->status == Connected && \t\ttype == P9_TFLUSH) { \t\tsigpending = 1; \t\tclear_thread_flag(TIF_SIGPENDING); \t\tgoto again; \t} clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72167", "url": "https://ubuntu.com/security/CVE-2026-72167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72171", "url": "https://ubuntu.com/security/CVE-2026-72171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: slram: remove failed entries from the device list register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72181", "url": "https://ubuntu.com/security/CVE-2026-72181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mips: sched: Fix CPUMASK_OFFSTACK memory corruption This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72182", "url": "https://ubuntu.com/security/CVE-2026-72182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: fix refcount leak in is_full_charged() In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72193", "url": "https://ubuntu.com/security/CVE-2026-72193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: cap RESTART_TABLE free-chain walker at rt->used A crafted NTFS3 disk image triggers an in-kernel infinite loop at mount time, hanging the mounting thread and firing the soft-lockup watchdog within ~22s on multi-CPU hosts (panic with kernel.softlockup_panic=1). The bug is reachable from desktop USB auto-mount on distributions where udisks2 routes the NTFS signature to the in-tree ntfs3 driver (Arch family and an increasing fraction of Fedora / openSUSE / RHEL deployments); CAP_SYS_ADMIN-class manual mount elsewhere. check_rstbl()'s second walker iterates the free-entry singly-linked list headed by rt->first_free with no upper bound on iteration count: for (off = ff; off;) { if (off == RESTART_ENTRY_ALLOCATED) return false; off = le32_to_cpu(*(__le32 *)Add2Ptr(rt, off)); if (off > ts - sizeof(__le32)) return false; } The existing guards cover three exits: end-of-list (off == 0), the in-use marker (off == RESTART_ENTRY_ALLOCATED), and out-of-bounds (off > ts - sizeof(__le32)). None of the three prevents an in-bounds cycle. A crafted on-disk RESTART_TABLE whose free chain contains a self-loop or A->B->A cycle whose offsets satisfy: - in range [sizeof(struct RESTART_TABLE), ts - sizeof(__le32)] - (off - sizeof(struct RESTART_TABLE)) % rsize == 0 passes all existing guards and spins the mount-time thread forever. Reproduced in UML by hand-forging a 2 MB NTFS3 image whose journal RESTART_TABLE first_free = 0x18 and whose entry at offset 0x18 stores 0x18 as its next pointer; mount of the forged image with the in-tree ntfs3 driver never returns. Bound the walker by rt->used. Each entry on a legitimate free chain is unique, and the total slot count is ne = le16_to_cpu (rt->used). A traversal that visits more than ne slots is by construction malformed; reject it as a corrupt RESTART_TABLE. After this patch, mount of the forged image returns with -EINVAL and a log_replay failure message, and mkntfs-produced legitimate images mount cleanly (verified in the same UML harness).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64532", "url": "https://ubuntu.com/security/CVE-2026-64532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation} In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is `Add2Ptr(e, le16_to_cpu(e->view.data_off))`, where e->view.data_off comes from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validates view.data_off + dlen against e->size; the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate the entry's offset, but not its internal view fields. The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <= e->size. Apply the same bound at the two memmove sites. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE. This is similar in shape to Pavitra Jha's 2026-05-02 patch \"fs/ntfs3: prevent oob in case UpdateRecordDataRoot\" (<20260502105008.21827-1-jhapavitra98@gmail.com>) which proposes calling ntfs3_bad_de_range(); that helper does not exist in mainline. This patch uses inline checks.", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64533", "url": "https://ubuntu.com/security/CVE-2026-64533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate lcns_follow in log_replay conversion log_replay() converts DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY records when replaying version 0 restart tables. During this conversion, the memmove() length is derived directly from the on-disk lcns_follow field: \tmemmove(&dp->vcn, &dp0->vcn_low, \t\t2 * sizeof(u64) + \t\t\t\tle32_to_cpu(dp->lcns_follow) * sizeof(u64)); check_rstbl() validates restart table structure, but does not constrain per-entry lcns_follow values relative to the entry size. A malformed filesystem image can provide an oversized lcns_follow value, causing the conversion memmove() to access memory beyond the bounds of the allocated restart table buffer. The same field is later used to bound iteration over page_lcns[], so validating lcns_follow during conversion also prevents downstream out-of-bounds access from the same malformed metadata. Compute the maximum valid lcns_follow from the already-validated restart table entry size and reject entries that exceed this bound. Reuse the existing t16/t32 scratch variables already declared in log_replay() to avoid introducing new declarations. [almaz.alexandrovich@paragon-software.com: fixed the conflicts]", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72195", "url": "https://ubuntu.com/security/CVE-2026-72195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment \tattr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72197", "url": "https://ubuntu.com/security/CVE-2026-72197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: \tif (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || \t Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || \t used + esize > le32_to_cpu(hdr->total)) { \t\tgoto dirty_vol; \t} Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72215", "url": "https://ubuntu.com/security/CVE-2026-72215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002. To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant. Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and \"if it ain't broke, don't fix it,\" so just leave them alone.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72218", "url": "https://ubuntu.com/security/CVE-2026-72218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72219", "url": "https://ubuntu.com/security/CVE-2026-72219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file leak when nlm_do_fopen() fails A client can repeatedly drive nlm_do_fopen() failures by presenting file handles that the underlying export rejects. After kzalloc_obj() succeeds in nlm_lookup_file(), the freshly allocated nlm_file is not yet inserted into nlm_files[]. The nlm_do_fopen() failure path jumps to out_unlock, which releases nlm_file_mutex and returns without freeing the allocation, so each failure leaks one nlm_file. Route the failure through out_free so kfree() runs before the function returns.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72223", "url": "https://ubuntu.com/security/CVE-2026-72223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arena sub-allocations on discover_arenas() error path Memory allocated by btt_freelist_init(), btt_rtt_init(), and btt_maplocks_init() is not freed on some discover_arenas() error paths. This leaks memory when arena discovery fails. Add the missing kfree() calls to release the allocations before returning an error. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72224", "url": "https://ubuntu.com/security/CVE-2026-72224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arenas on btt_init() error paths The arenas allocated by discover_arenas() or create_arenas() are not freed on some error paths in btt_init(). This leaks memory when BTT initialization fails. Call free_arenas() from the affected error paths to release the allocations. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72225", "url": "https://ubuntu.com/security/CVE-2026-72225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit() jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check. The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort. Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72228", "url": "https://ubuntu.com/security/CVE-2026-72228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: fix primary_if leak on failed linearization If the skb has a frag_list, it must be linearized before it can be split using skb_split(). But when this step failed, it must not only free the skb but also take care of the reference to the already found primary_if.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72230", "url": "https://ubuntu.com/security/CVE-2026-72230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72231", "url": "https://ubuntu.com/security/CVE-2026-72231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is \"ret == false\". But the actual implementation is checking for \"ret == true\". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72233", "url": "https://ubuntu.com/security/CVE-2026-72233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: reacquire gw address after skb realloc The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72238", "url": "https://ubuntu.com/security/CVE-2026-72238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/boot: Validate console=uart8250 baud rate to fix early boot hang When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72240", "url": "https://ubuntu.com/security/CVE-2026-72240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72241", "url": "https://ubuntu.com/security/CVE-2026-72241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: uleds: Fix potential buffer overread The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72245", "url": "https://ubuntu.com/security/CVE-2026-72245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64554", "url": "https://ubuntu.com/security/CVE-2026-64554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() br_ip6_fragment() gets prevhdr, a pointer into the skb head, from ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb skb_checksum_help() reallocates the head via pskb_expand_head(), leaving prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a use-after-free write. Save prevhdr's offset before skb_checksum_help() and recompute it after, like commit ef0efcd3bd3f (\"ipv6: Fix dangling pointer when ipv6 fragment\"). BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857) Write of size 1 at addr ffff888013ff5016 by task exploit/141 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip6_frag_next (net/ipv6/ip6_output.c:857) br_ip6_fragment (net/ipv6/netfilter.c:212) nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407) nf_hook_slow (net/netfilter/core.c:619) br_forward_finish (net/bridge/br_forward.c:66) __br_forward (net/bridge/br_forward.c:115) maybe_deliver (net/bridge/br_forward.c:191) br_flood (net/bridge/br_forward.c:245) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:442) ... packet_sendmsg (net/packet/af_packet.c:3114) ... do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72247", "url": "https://ubuntu.com/security/CVE-2026-72247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: fix zone comparison in tuple dedup The \"already exists\" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument. Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone. nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents. Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72250", "url": "https://ubuntu.com/security/CVE-2026-72250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header: \tskb->mac_header += sizeof(struct frag_hdr); On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the \"not set\" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom. The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72256", "url": "https://ubuntu.com/security/CVE-2026-72256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_cluster: reject template conntracks in hash match xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72264", "url": "https://ubuntu.com/security/CVE-2026-72264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tridentfb: fix potential memory leak in trident_pci_probe() In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72265", "url": "https://ubuntu.com/security/CVE-2026-72265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: nvidia: fix potential memory leak in nvidiafb_probe() In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72267", "url": "https://ubuntu.com/security/CVE-2026-72267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: carminefb: fix potential memory leak in alloc_carmine_fb() The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72268", "url": "https://ubuntu.com/security/CVE-2026-72268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe() In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72269", "url": "https://ubuntu.com/security/CVE-2026-72269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: fix potential memory leak in uvesafb_probe() Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. Fix this by updating the goto label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72270", "url": "https://ubuntu.com/security/CVE-2026-72270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: s3fb: fix potential memory leak in s3_pci_probe() In s3_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72271", "url": "https://ubuntu.com/security/CVE-2026-72271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: i740fb: fix potential memory leak in i740fb_probe() In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72272", "url": "https://ubuntu.com/security/CVE-2026-72272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: radeon: fix potential memory leak in radeonfb_pci_register() The function radeonfb_pci_register() allocates memory for modelist (by calling radeon_check_modes() which calls fb_add_videomode()). The memory is appended to info->modelist, but is not freed in subsequent error paths. Fix this by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72274", "url": "https://ubuntu.com/security/CVE-2026-72274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: hecubafb: fix potential memory leak in hecubafb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72275", "url": "https://ubuntu.com/security/CVE-2026-72275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72276", "url": "https://ubuntu.com/security/CVE-2026-72276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: metronomefb: fix potential memory leak in metronomefb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72297", "url": "https://ubuntu.com/security/CVE-2026-72297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72298", "url": "https://ubuntu.com/security/CVE-2026-72298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with \tif (!size || len != ALIGN(size, 4) + hdrlen) \t\tgoto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 (\"net: qrtr: fix OOB Read in qrtr_endpoint_post\"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72306", "url": "https://ubuntu.com/security/CVE-2026-72306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72307", "url": "https://ubuntu.com/security/CVE-2026-72307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree. Fix by reinitializing vr inside the error loop with the updated index: \tvr = &mlxsw_sp->router->vrs[i]; so that the loop correctly iterates over all VRs that were actually replaced.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72310", "url": "https://ubuntu.com/security/CVE-2026-72310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds.", "cve_priority": "negligible", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72314", "url": "https://ubuntu.com/security/CVE-2026-72314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72316", "url": "https://ubuntu.com/security/CVE-2026-72316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix NULL pointer dereference in metadata_open() metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72326", "url": "https://ubuntu.com/security/CVE-2026-72326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cake: reject overhead values that underflow length CAKE accepts signed overhead values and stores them in an s16, but the adjusted packet length calculation uses unsigned arithmetic. A negative effective length can therefore wrap to a large value. Such configurations make rate accounting depend on integer wraparound rather than on the packet size userspace intended to model. A static netlink lower bound is not enough because packets reaching CAKE can be smaller than any reasonable manual-overhead allowance. Fold the signed overhead adjustment into the existing datapath MPU clamp so negative adjusted lengths are clamped before link-layer framing adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64549", "url": "https://ubuntu.com/security/CVE-2026-64549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup() bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length: \tbt_dev_info(hdev, \"%s\", (char *)(skb->data + 1)); \thci_set_fw_info(hdev, \"%s\", skb->data + 1); A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file. Print the revision string with a bounded \"%.*s\" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64550", "url": "https://ubuntu.com/security/CVE-2026-64550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: validate MAP frame length before ingress parsing When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes the skb straight to __rmnet_map_ingress_handler(), skipping the length validation that rmnet_map_deaggregate() performs on the aggregated path. The parser then dereferences the MAP header and csum header/trailer based on the on-wire pkt_len without checking skb->len, so a short frame is read out of bounds: BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet Read of size 1 at addr ffff88801118ed00 by task exploit/147 Call Trace: ... rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413) __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089) netif_receive_skb (net/core/dev.c:6460) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2001) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Factor that validation out of rmnet_map_deaggregate() into rmnet_map_validate_packet_len() and run it on the no-aggregation path too. The MAP header is bounds-checked first, since this path can receive a frame shorter than the header.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72347", "url": "https://ubuntu.com/security/CVE-2026-72347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_connmark: reject invalid shift parameters Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmark_tg_shift(). A shift_bits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shift_dir values are also accepted and silently fall back to the left-shift path. Reject invalid revision-2 shift parameters in connmark_tg_check() so malformed rules fail at installation time, before they can reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72349", "url": "https://ubuntu.com/security/CVE-2026-72349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt() On links faster than ~34 Gbps, where byte rate may exceed 2^32-1 (~ 4.3 GBps), the comparison result becomes incorrect because the truncated value no longer reflects the actual estimator rate. Fix by changing the local variables to u64.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72350", "url": "https://ubuntu.com/security/CVE-2026-72350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_u32: reject invalid shift counts u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation. Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64547", "url": "https://ubuntu.com/security/CVE-2026-64547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: net1080: validate packet_len before pad-byte access in rx_fixup For an even packet_len, net1080_rx_fixup() reads the pad byte at skb->data[packet_len] before the skb->len != packet_len check further down, and packet_len is only bounded against NC_MAX_PACKET. A malicious NetChip 1080 device can send a short frame advertising a large even packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the skb: BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14 ... net1080_rx_fixup (drivers/net/usb/net1080.c:384) usbnet_bh (drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3708) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) ... Reject the frame when packet_len >= skb->len before reading.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72371", "url": "https://ubuntu.com/security/CVE-2026-72371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the volume AFS_VOLUME_RM_TREE is set on Fix afs_insert_volume_into_cell() to set AFS_VOLUME_RM_TREE on the volume replaced, not the new volume, as it's now removed from the cell's volume tree. This will cause the old volume to be removed from the tree twice and the new volume never to be removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72374", "url": "https://ubuntu.com/security/CVE-2026-72374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix callback service message parsers to pass through -EAGAIN The AFS filesystem client uses an rxrpc server to listen for callback notifications. Each callback call type handler has a delivery function that parses the incoming request stream, and this should return -EAGAIN the last packet hasn't yet been seen, but all currently queued received data is consumed. afs_extract_data() does this, but the -EAGAIN return is switched to 0 inadvertantly Fix callback service message parsers to pass through -EAGAIN", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72378", "url": "https://ubuntu.com/security/CVE-2026-72378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix error code in afs_extract_vl_addrs() The error codes on these paths are only set on the first iteration through the loop. Set the correct error code on every iteration.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72389", "url": "https://ubuntu.com/security/CVE-2026-72389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: stp: Fix a potential use-after-free when deleting a bridge The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them. This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted. Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted. [1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64540", "url": "https://ubuntu.com/security/CVE-2026-64540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup() genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received. A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes. \tskb_put_data(gl_skb, packet->packet_data, size); then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up. BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72392", "url": "https://ubuntu.com/security/CVE-2026-72392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72396", "url": "https://ubuntu.com/security/CVE-2026-72396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: adm1275: Prevent reading uninitialized stack While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret < 0) { ... } for (mid = adm1275_id; mid->name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like \"adm12\", checking it against \"adm1275\" up to the length of \"adm1275\" will continue reading into uninitialized stack bounds. Prevent reading uninitialized memory by zeroing the stack array.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72400", "url": "https://ubuntu.com/security/CVE-2026-72400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: validate SRH length before reading fixed fields seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields. The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer. Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72406", "url": "https://ubuntu.com/security/CVE-2026-72406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sungem: fix probe error cleanup gem_init_one() calls gem_remove_one() when register_netdev() fails. gem_remove_one() unregisters and frees resources owned by the net_device, including the DMA block, MMIO mapping, PCI regions, and the net_device itself. gem_init_one() then falls through to its own cleanup labels and frees the same resources again. Keep the register_netdev() error path in gem_init_one(): clear drvdata so PM/remove paths do not see a half-registered device, remove the NAPI instance added during probe, and let the existing cleanup labels release the resources once. The issue was found by a local static-analysis checker for probe error paths. The reported path was manually inspected before sending this fix. Compile-tested with CONFIG_SUNGEM=y. Runtime testing was not performed because no sungem hardware is available.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72409", "url": "https://ubuntu.com/security/CVE-2026-72409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvneta: re-enable percpu interrupt on resume On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules NAPI poll, which calls enable_percpu_irq() on completion to unmask. If suspend occurs while NAPI poll is pending (between disable_percpu_irq in the ISR and enable_percpu_irq in poll completion), the interrupt is never re-enabled: 1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule() => MPIC masked, percpu_enabled cpumask bit cleared 2. NAPI poll does not complete before suspend proceeds (on PREEMPT_RT this is highly likely since softirqs run in ksoftirqd which gets frozen; on non-RT it can happen when softirq processing is deferred to ksoftirqd) 3. mvneta_stop_dev => napi_disable(): cancels the pending poll without executing the completion path 4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC (already masked, but records IRQS_SUSPENDED) 5. Resume: mpic_resume checks irq_percpu_is_enabled() => false (bit was cleared in step 1) => skips unmask 6. mvneta_start_dev only restores device-level INTR_NEW_MASK, does not touch the MPIC per-CPU mask Result: MPIC per-CPU interrupt stays masked permanently. The NIC generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never receives them, causing complete loss of network connectivity. Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path to unconditionally unmask the MPIC per-CPU interrupt regardless of pre-suspend state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72414", "url": "https://ubuntu.com/security/CVE-2026-72414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: round up PTP perout pin duration pin_duration is converted from the user-provided period to SJA1105 clock ticks and is later passed as the cycle_time argument to future_base_time(). Very small period values may become zero after the conversion, which can lead to a division by zero in future_base_time(). Round zero pin_duration up to 1 tick so that the smallest unsupported periods use the minimum non-zero hardware duration instead of passing zero to future_base_time().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64545", "url": "https://ubuntu.com/security/CVE-2026-64545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net, bpf: check master for NULL in xdp_master_redirect() xdp_master_redirect() dereferences the result of netdev_master_upper_dev_get_rcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency. The reach guard only checks netif_is_bond_slave(). On bond slave release bond_upper_dev_unlink() drops the upper-master adjacency before clearing IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window still passes netif_is_bond_slave() while master is already NULL, and faults on master->flags at offset 0xb0: BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdp_master_redirect (net/core/filter.c:4432) Call Trace: xdp_master_redirect (net/core/filter.c:4432) bpf_prog_run_generic_xdp (include/net/xdp.h:700) do_xdp_generic (net/core/dev.c:5608) __netif_receive_skb_one_core (net/core/dev.c:6204) process_backlog (net/core/dev.c:6319) __napi_poll (net/core/dev.c:7729) net_rx_action (net/core/dev.c:7792) handle_softirqs (kernel/softirq.c:622) __dev_queue_xmit (include/linux/bottom_half.h:33) packet_sendmsg (net/packet/af_packet.c:3082) __sys_sendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt The missing check dates back to the original code; commit 1921f91298d1 (\"net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master\") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72418", "url": "https://ubuntu.com/security/CVE-2026-72418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: prevent connlimit drops for early confirmed ct Commit 69894e5b4c5e (\"netfilter: nft_connlimit: update the count if add was skipped\") introduced a regression where packets for valid connections are dropped when using connlimit for soft-limiting scenarios. The issue occurs when a new connection reuses a socket currently in the TIME_WAIT state. In this scenario, the connection tracking entry is evaluated as already confirmed. Previously, __nf_conncount_add() assumed that if a connection was confirmed and did not originate from the loopback interface, it should skip the addition and return -EEXIST. Skipping the addition triggers a garbage collection run that cleans up the TIME_WAIT connection. Consequently, the active connection count drops to 0, which xt_connlimit mishandles, leading to the false rejection of the perfectly valid new connection. Fix this by replacing the interface check with protocol-agnostic state checks. We now skip the tree insertion and preserve the lockless garbage collection optimization only if the connection is IPS_ASSURED. This allows early-confirmed setup packets (such as reused TIME_WAIT sockets or locally generated SYN-ACKs) to be properly evaluated and counted without falsely dropping. The goto check_connections path is maintained to ensure these setup packets are deduplicated correctly. This has been tested with slowhttptest and HTTP server configured locally to ensure we are not breaking soft-limiting scenarios for local or external connections. In addition, it was tested with a OVS zone limit too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72421", "url": "https://ubuntu.com/security/CVE-2026-72421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't ignore error route in local/main tables. When CONFIG_IP_MULTIPLE_TABLES is enabled but no rule is added, fib_lookup() performs route lookup directly on two tables. Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table: # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache Once a random rule is added, the error route is respected: # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host Let's fix the inconsistent behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64538", "url": "https://ubuntu.com/security/CVE-2026-64538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix null-ptr-deref in fib6_nh_mtu_change(). fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown() clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(), but this re-fetch is unguarded; nexthop-backed routes survive addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is nulled. Return 0 when idev is NULL, matching rt6_mtu_change_route() and the fib6_mtu() fix in commit 5ad509c1fdad (\"ipv6: Fix null-ptr-deref in fib6_mtu().\"). Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6_nh_mtu_change+0x203/0x990 rt6_mtu_change_route+0x141/0x1d0 __fib6_clean_all+0xd0/0x160 rt6_mtu_change+0xb4/0x100 ndisc_router_discovery+0x24b5/0x2cb0 icmpv6_rcv+0x12e9/0x1710 ipv6_rcv+0x39b/0x410", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64546", "url": "https://ubuntu.com/security/CVE-2026-64546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72428", "url": "https://ubuntu.com/security/CVE-2026-72428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack slot index in nospec checks check_stack_write_fixed_off() computes the byte slot for a fixed-offset stack write as -off - 1, and records each written byte in slot_type[] with (slot - i) % BPF_REG_SIZE. The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a 4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates bytes 7..4. That can leave the second half-slot write without nospec_result even though the bytes being overwritten still require sanitization. Use the same slot index in the sanitization pre-check that the write path uses when updating slot_type[].", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72433", "url": "https://ubuntu.com/security/CVE-2026-72433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak This needs to test for nonzero retval.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72435", "url": "https://ubuntu.com/security/CVE-2026-72435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer() Sashiko pointed out that kfree_rcu() was called before rcu_assign_pointer() in handling the comment extension. Fix the order so that rcu_assign_pointer() called first.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72441", "url": "https://ubuntu.com/security/CVE-2026-72441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: fix kernel-infoleak in dgram_recvmsg() KMSAN reported a kernel-infoleak in move_addr_to_user(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925 ... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739 The issue occurs because the `pan_id` field of `struct ieee802154_addr` is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`. The execution flow is as follows: 1. `__ieee802154_rx_handle_packet()` declares a local `struct ieee802154_hdr hdr` on the stack. 2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse the source and destination addresses into this structure. 3. If the address mode is `IEEE802154_ADDR_NONE`, `ieee802154_hdr_get_addr()` previously only set the `mode` field, leaving the `pan_id` field containing uninitialized stack memory. 4. This uninitialized `pan_id` is later copied into a `struct sockaddr_ieee802154` in `dgram_recvmsg()` via `ieee802154_addr_to_sa()`. 5. Finally, `move_addr_to_user()` copies the socket address structure to user space, leaking the uninitialized bytes. Fix this by using `memset` to zero out the address structure in `ieee802154_hdr_get_addr()` when the mode is `IEEE802154_ADDR_NONE`.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72447", "url": "https://ubuntu.com/security/CVE-2026-72447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: hold socket lock when dumping endpoints in sctp_diag SCTP_DIAG endpoint dumping was traversing endpoint address lists without holding lock_sock(), while those lists could change concurrently via socket operations (e.g., bindx changes). This creates a race where nla_reserve() counts addresses under RCU protection, but the subsequent copy may see fewer entries, potentially leaking uninitialized memory to userspace. Fix this by: - Taking a reference on each endpoint during hash traversal - Moving socket operations (lock_sock()) outside read_lock_bh() - Serializing address list access during dump - Reworking sctp_for_each_endpoint() to support restart-based traversal with (net, pos) tracking Also: - Add WARN_ON_ONCE() for inconsistent address counts - Fix idiag_states filtering for LISTEN vs association cases - Skip dumping endpoints being freed (ep->base.dead) - Move dump position tracking into iterator, removing cb->args[4] and its comment for sctp_ep_dump()., - Update the comment for cb->args[4] and remove the comment for unused cb->args[5] for sctp_sock_dump(). Note: traversal is restart-based and may re-scan buckets multiple times, but this is acceptable due to small bucket sizes and required to support sleeping-safe callbacks. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64553", "url": "https://ubuntu.com/security/CVE-2026-64553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: psample: fix info leak in PSAMPLE_ATTR_DATA psample open codes nla_put() presumably to avoid wiping the data with 0s just to override it with packet data. This open coding is missing clearing the pad, however, each netlink attr is padded to 4B and data_len may not be divisible by 4B.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72448", "url": "https://ubuntu.com/security/CVE-2026-72448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix leak of SQ timestamp buffer on teardown The send-queue timestamp ring is allocated with qmem_alloc() when timestamping is used, but otx2_free_sq_res() never freed sq->timestamps, leaking that memory across ifdown and device removal. Add the missing qmem_free() alongside the other SQ companion buffers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72450", "url": "https://ubuntu.com/security/CVE-2026-72450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate selector family and prefixlen during match syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72459", "url": "https://ubuntu.com/security/CVE-2026-72459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: aa_label_alloc use aa_label_free on alloc failure aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init(). Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72460", "url": "https://ubuntu.com/security/CVE-2026-72460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72476", "url": "https://ubuntu.com/security/CVE-2026-72476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix possible use after free In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72479", "url": "https://ubuntu.com/security/CVE-2026-72479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: mma8452: handle I2C read error(s) in mma8452_read() Currently, If i2c_smbus_read_i2c_block_data() fails but mma8452_set_runtime_pm_state() succeeds, mma8452_read() returns 0. As a result, the caller mma8452_read_raw() assumes the read was successful and proceeds to use a buffer containing uninitialized stack memory. Add proper checking of the I2C read return value and propagate errors to the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72481", "url": "https://ubuntu.com/security/CVE-2026-72481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: ak8975: fix potential kernel stack memory leak Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72483", "url": "https://ubuntu.com/security/CVE-2026-72483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72484", "url": "https://ubuntu.com/security/CVE-2026-72484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: video: avoid double free on video register failure comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72489", "url": "https://ubuntu.com/security/CVE-2026-72489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: nvec: fix use-after-free in nvec_rx_completed() In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72492", "url": "https://ubuntu.com/security/CVE-2026-72492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in same_client_has_lease() same_client_has_lease() returns an opinfo pointer from ci->m_op_list after dropping ci->m_lock without taking a reference. smb_grant_oplock() then dereferences that pointer in copy_lease() and when checking breaking_cnt. A concurrent close can remove the old lease from ci->m_op_list and drop the last reference before the caller uses the returned pointer, leading to a use-after-free. Take a reference when same_client_has_lease() selects an existing lease, drop any previous match while scanning, and release the returned reference in smb_grant_oplock() after copying the lease state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72502", "url": "https://ubuntu.com/security/CVE-2026-72502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF) When MTU is large, ip6_default_advmss() can return IPV6_MAXPLEN (65535). This is interpreted by TCP as mss_clamp, allowing the MSS to reach 65535. However, 0xFFFF is also used as a magic value GSO_BY_FRAGS in the kernel. If a TCP packet with gso_size=0xFFFF is passed to skb_segment(), it will be mistakenly treated as GSO_BY_FRAGS, leading to a NULL pointer dereference because local TCP packets do not use frag_list. Fix this by returning min(IPV6_MAXPLEN, GSO_BY_FRAGS - 1) (65534) from ip6_default_advmss() when MTU is large. Also update the stale comment in ip6_default_advmss() which suggested that IPV6_MAXPLEN is returned to mean \"any MSS\".", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74256", "url": "https://ubuntu.com/security/CVE-2026-74256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check start and len are u32, so \tu64 last = start + len; evaluates start + len in 32-bit and wraps before storing it in last. The bounds check \tif (start >= offset + l || last > msg->sg.size) \t\treturn -EINVAL; can then be passed with an out-of-range start/len, after which the pop loop runs off the end of the scatterlist and sk_msg_shift_left() calls put_page() on the empty msg->sg.end slot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:sk_msg_shift_left net/core/filter.c:2957 [inline] RIP: 0010:____bpf_msg_pop_data net/core/filter.c:3103 [inline] RIP: 0010:bpf_msg_pop_data+0x753/0x1a10 net/core/filter.c:2984 Call Trace: bpf_prog_4cc92c278f4d5d56+0x1b1/0x1e8 bpf_prog_run_pin_on_cpu+0x107/0x320 include/linux/filter.h:746 sk_psock_msg_verdict+0x357/0x7f0 net/core/skmsg.c:934 tcp_bpf_send_verdict net/ipv4/tcp_bpf.c:420 [inline] tcp_bpf_sendmsg+0x766/0x1ae0 net/ipv4/tcp_bpf.c:583 __sock_sendmsg+0x153/0x1c0 net/socket.c:802 __sys_sendto+0x326/0x430 net/socket.c:2265 __x64_sys_sendto+0xe3/0x100 net/socket.c:2268 do_syscall_64+0x14c/0x480 entry_SYSCALL_64_after_hwframe+0x77/0x7f Widen the addition with a (u64) cast so the bound is evaluated in 64-bit and a len near U32_MAX no longer wraps below msg->sg.size. While here, change pop from int to u32. It counts bytes against the unsigned scatterlist lengths and can never be negative, so the signed type only invites sign-confusion in the pop loop.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64548", "url": "https://ubuntu.com/security/CVE-2026-64548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data() When the scatterlist ring is full or nearly full, bpf_msg_push_data() enters a copy fallback path and computes copy + len for the page allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING and both are u32, a crafted len can wrap the sum to a small value, causing an undersized allocation followed by an out-of-bounds memcpy. BUG: unable to handle page fault for address: ffffed104089a402 Oops: Oops: 0000 [#1] SMP KASAN NOPTI Call Trace: __asan_memcpy (mm/kasan/shadow.c:105) bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) bpf_prog_9ed8b5711920a7d7+0x2e/0x36 sk_psock_msg_verdict (net/core/skmsg.c:934) tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) __sys_sendto (net/socket.c:2206) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add an overflow check before the allocation.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74262", "url": "https://ubuntu.com/security/CVE-2026-74262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcm: use WRITE_ONCE() when changing lower socket callbacks kcm_attach() replaces a live lower TCP socket's sk_data_ready and sk_write_space callbacks with KCM handlers, and kcm_unattach() restores them later. Those callback-pointer updates are still plain stores even though the same fields can be read and invoked concurrently on other CPUs. If another CPU observes an older callback snapshot after the live field has already been restored, callback execution can run with a mismatched target and sk_user_data state, leading to stale or misdirected wakeups. Use WRITE_ONCE() for the callback replacement and restore operations so these shared callback fields follow the same visibility contract already established by the earlier 4022 fixes.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74265", "url": "https://ubuntu.com/security/CVE-2026-74265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: initialize gdma queue id to INVALID_QUEUE_ID mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74276", "url": "https://ubuntu.com/security/CVE-2026-74276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: xilinx: use FIFO occupancy register to determine buffer size The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. When a SPI transaction wants to write the amount of the FIFO size or more bytes, the following happens, for example with 16 bytes FIFO size: The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and starts the SPI hardware and goes sleep. The hardware then shifts out 17 bytes (FIFO + shift register) and simultaneously reads bytes into the RX FIFO, but it only has 16 places, so it looses one byte. Then TX FIFO empty asserts, wakes the driver again, which has a fast path and reads 16 bytes from the RX FIFO, but before reading the last 17th byte (which is lost) it does this: \tsr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); \tif (!(sr & XSPI_SR_RX_EMPTY_MASK)) { \t\txilinx_spi_rx(xspi); \t\trx_words--; \t} It reads the status register and checks if the RX FIFO is not empty. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74279", "url": "https://ubuntu.com/security/CVE-2026-74279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: cavium/cpt - fix DMA cleanup using wrong loop index The sg_cleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74280", "url": "https://ubuntu.com/security/CVE-2026-74280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/octeontx - fix DMA cleanup using wrong loop index The sg_cleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74281", "url": "https://ubuntu.com/security/CVE-2026-74281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74282", "url": "https://ubuntu.com/security/CVE-2026-74282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: prevent snt_unacked underflow on CONN_ACK tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: \ttsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74283", "url": "https://ubuntu.com/security/CVE-2026-74283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74284", "url": "https://ubuntu.com/security/CVE-2026-74284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: Don't make class passive twice update_vf() is called from two places for the same class during a single dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last packets while dequeuing: 1. The child calls qdisc_tree_reduce_backlog(), which, now that the child is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns the class passive (cl_nactive is decremented up the hierarchy). 2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time) to charge the dequeued bytes. On the second call the class is already passive, but its child qdisc is still empty, so update_vf() arms go_passive again: if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1; The leaf is then skipped by the cl_nactive == 0 check inside the loop, which does not clear go_passive, so the stale go_passive propagates to the parent and decrements its cl_nactive a second time. A parent that still has other active children is driven to cl_nactive == 0 and removed from the vttree, even though those siblings are still backlogged. They are never dequeued again and the qdisc stalls. Fix this by only arming go_passive when the class is actually active, so an already-passive class no longer triggers a second passive transition. The byte accounting (cl->cl_total += len) still runs for every ancestor, so dequeued bytes continue to be counted exactly once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64537", "url": "https://ubuntu.com/security/CVE-2026-64537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: reject invalid CCM interval at configuration time ccm_tx_work_expired() re-arms itself via queue_delayed_work() using the configured exp_interval converted by interval_to_us(). When exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range, interval_to_us() returns 0, causing the worker to fire immediately in a tight loop that allocates skbs until OOM. Fix this by validating exp_interval at configuration time: - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the netlink policy so userspace cannot set an invalid value. - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not yet been configured (defaults to 0 from kzalloc).", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74288", "url": "https://ubuntu.com/security/CVE-2026-74288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fib_rules: Don't dump dying fib_rule in fib_rules_dump(). rocker_router_fib_event() calls fib_rule_get() during RCU dump. If the fib_rule is dying, refcount_inc() will complain about it. Let's call refcount_inc_not_zero() in fib_rules_dump().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74292", "url": "https://ubuntu.com/security/CVE-2026-74292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tegra: tegra210_ahub: Validate written enum value tegra_ahub_put_value_enum() reads e->values[item[0]] before checking whether item[0] is within the enum item range. The existing check therefore happens too late to prevent an out-of-range read of the values array. Move the check before the array access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74293", "url": "https://ubuntu.com/security/CVE-2026-74293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: fsl_audmix: Validate written enum values fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src() convert the user-provided enum item with snd_soc_enum_item_to_val() before checking whether the item is within the enum's item count. The generic snd_soc_put_enum_double() helper performs that validation, but these callbacks use the converted value first: the clock-source path tests it with BIT(), and the output-source path indexes the prms transition table with it. Reject out-of-range enum items before converting them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74295", "url": "https://ubuntu.com/security/CVE-2026-74295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: hdac_hdmi: Validate written enum value hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range. An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74297", "url": "https://ubuntu.com/security/CVE-2026-74297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix undefined shift of user RQ WQE size set_rq_size() computes the RQ WQE size as \"1 << rq_wqe_shift\" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74305", "url": "https://ubuntu.com/security/CVE-2026-74305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tighten cgroup storage cookie checks for prog arrays The fix in commit abad3d0bad72 (\"bpf: Fix oob access in cgroup local storage\") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74312", "url": "https://ubuntu.com/security/CVE-2026-74312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: validate virtqueue index in mmap and fault paths vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74313", "url": "https://ubuntu.com/security/CVE-2026-74313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: hold vduse_lock across IDR lookup in open path vduse_dev_open() looks up struct vduse_dev through the IDR and then acquires dev->lock only after vduse_lock has been dropped. This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the same object from the IDR and free it before the open path locks the device, leading to a use-after-free. Close this race by keeping vduse_lock held until dev->lock has been acquired in the open path, matching the lock ordering already used by the destroy path.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74320", "url": "https://ubuntu.com/security/CVE-2026-74320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, \"mode\", &len) is just written over either the static \"640x480-16@60\" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74321", "url": "https://ubuntu.com/security/CVE-2026-74321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 (\"btrfs: refactor __btrfs_run_delayed_refs loop\") but were unintentionally lost afterwards.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74327", "url": "https://ubuntu.com/security/CVE-2026-74327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmalloc: fix NULL pointer dereference in is_vm_area_hugepages() find_vm_area() can return NULL if the given address is not a valid vmalloc area. Check the return value before dereferencing it to avoid a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74329", "url": "https://ubuntu.com/security/CVE-2026-74329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: unregister PM notifier on watchdog unregister watchdog_register_device() registers wdd->pm_nb when WDOG_NO_PING_ON_SUSPEND is set, but watchdog_unregister_device() does not remove it. This leaves an embedded notifier block on the PM notifier chain after the watchdog device has been unregistered. A later suspend/resume notification can then call watchdog_pm_notifier() with a stale watchdog_device pointer, or at minimum after wdd->wd_data has been cleared by watchdog_dev_unregister(). Unregister the PM notifier before tearing down the watchdog device.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74330", "url": "https://ubuntu.com/security/CVE-2026-74330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: fix lockless traversals of ->s_children Having the parent directory locked protects entries from removal by another thread, but it does *not* protect cursors from being moved around by lseek() - or freed, for that matter.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74331", "url": "https://ubuntu.com/security/CVE-2026-74331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix recursive lock in device_cache_fw_images() A recursive locking deadlock can occur in the firmware loader's power management notification handler. During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock. For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread. The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock. Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74339", "url": "https://ubuntu.com/security/CVE-2026-74339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Clear variable event pointer on read snd_seq_read() copies a queued variable-length event header to userspace before expanding the payload. Queued variable-length events use SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first extension cell. The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the copy, but it leaves data.ext.ptr untouched. A userspace sequencer client can therefore write a direct variable event to itself and read back the extension-cell kernel address from the returned header. Clear the temporary header pointer before copy_to_user(). The original queued event remains unchanged and is still passed to snd_seq_expand_var_event(), so payload expansion keeps using the internal chain.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74340", "url": "https://ubuntu.com/security/CVE-2026-74340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74346", "url": "https://ubuntu.com/security/CVE-2026-74346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74348", "url": "https://ubuntu.com/security/CVE-2026-74348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: require a ref for locking_state debugfs open debug_lockres_open() copies inode->i_private into struct debug_lockres and debug_lockres_release() later drops that pointer with dlm_put(). That only works if open successfully pins the struct dlm_ctxt. Today open calls dlm_grab(dlm) but ignores its return value. Once the last domain unregister has removed the context from dlm_domains, dlm_grab() returns NULL, yet open still stores the raw pointer and returns success. The later release path is outside the debugfs removal barrier, so it can call dlm_put() after dlm_free_ctxt_mem() has freed the context. KASAN reports this as a slab-use-after-free in dlm_put() called from debug_lockres_release(). Fail the open when dlm_grab() cannot acquire the reference and unwind the seq_file private state before returning. That keeps locking_state from handing out a file descriptor whose release path does not own the dlm_ctxt. The buggy scenario involves two paths, with each column showing the order within that path: locking_state debugfs open: last domain unregister: 1. debug_lockres_open() reads 1. dlm_unregister_domain() calls inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() calls 2. shutdown removes the dlm_ctxt from dlm_grab(dlm) and gets NULL. dlm_domains. 3. open still stores the raw dlm 3. final teardown reaches pointer in dl->dl_ctxt and dlm_free_ctxt_mem() and frees it. returns success. 4. debug_lockres_release() later calls dlm_put(dl->dl_ctxt). Validation reproduced this kernel report: KASAN slab-use-after-free in dlm_put+0x82/0x200 RIP: 0033:0x7f4d349bc9e0 The buggy address belongs to the object at ffff888103a3c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 816 bytes inside of freed 2048-byte region [ffff888103a3c000, ffff888103a3c800) Write of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) dlm_put+0x82/0x200 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) kasan_check_range+0x105/0x1b0 (?:?) debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) dlm_put+0x9/0x200 (?:?) debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) full_proxy_release+0x67/0x90 (?:?) __fput+0x1df/0x4b0 (?:?) do_raw_spin_lock+0x10f/0x1b0 (?:?) fput_close_sync+0xd2/0x170 (?:?) __x64_sys_close+0x55/0x90 (?:?) do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87) irqentry_exit+0xac/0x6e0 (?:?) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Freed by task stack: kasan_save_stack+0x33/0x60 (?:?) kasan_save_track+0x14/0x30 (?:?) kasan_save_free_info+0x3b/0x60 (?:?) __kasan_slab_free+0x5f/0x80 (?:?) kfree+0x30f/0x580 (?:?) dlm_put+0x1ce/0x200 (?:?) dlm_unregister_domain+0xf6/0xb30 (?:?) o2cb_cluster_disconnect+0x6b/0x90 (?:?) ocfs2_cluster_disconnect+0x41/0x70 (?:?) ocfs2_dlm_shutdown+0x1c4/0x220 (?:?) ocfs2_dismount_volume+0x38a/0x550 (?:?) generic_shutdown_super+0xc3/0x220 (?:?) kill_block_super+0x29/0x60 (?:?) deactivate_locked_super+0x66/0xe0 (?:?) cleanup_mnt+0x13d/0x210 (?:?) task_work_run+0xfa/0x170 (?:?) exit_to_user_mode_loop+0xd6/0x430 (?:?) do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74349", "url": "https://ubuntu.com/security/CVE-2026-74349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject FITRIM ranges shorter than a cluster ocfs2_trim_mainbm() trims the global bitmap in cluster units, but its too-short range validation only checks sb->s_blocksize. On filesystems with a cluster size larger than the block size, a FITRIM range that is at least one block but shorter than one cluster is accepted and shifted down to len == 0. The later start + len - 1 and len -= ... arithmetic then underflows and can drive trimming past the requested range. Reject ranges shorter than s_clustersize instead. That preserves the existing -EINVAL behavior for requests that cannot discard even one allocation unit and keeps zero-cluster trims out of the group walk.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74351", "url": "https://ubuntu.com/security/CVE-2026-74351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74359", "url": "https://ubuntu.com/security/CVE-2026-74359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs_lookup(): don't leave ->s_dentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74363", "url": "https://ubuntu.com/security/CVE-2026-74363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs commit 4f375ade6aa9 (\"bpf: Avoid RCU context warning when unpinning htab with internal structs\") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.). This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime(). KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags) The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74379", "url": "https://ubuntu.com/security/CVE-2026-74379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax/kmem: account for partial discontiguous resource upon removal When dev_dax_kmem_probe() partially succeeds (at least one range is mapped) but a subsequent range fails request_mem_region() or add_memory_driver_managed(), the probe silently continues, ultimately returning success, but with the corresponding range resource NULL'ed out. dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the underlying resource exists. When remove_memory() is called later, it returns 0 because the memory was never added which causes dev_dax_kmem_remove() to incorrectly assume the (nonexistent) resource can be removed and attempts cleanup on a NULL pointer. Fix this by skipping these ranges altogether, noting that these cases are considered success, such that the cleanup is still reached when all actually-added ranges are successfully removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74382", "url": "https://ubuntu.com/security/CVE-2026-74382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74390", "url": "https://ubuntu.com/security/CVE-2026-74390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr->pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don't overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74395", "url": "https://ubuntu.com/security/CVE-2026-74395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list before initializing the fields used by the shared error path. If eventfd_ctx_fdget() then fails, the unwind path dereferences event_sub->ev_file in uverbs_uobject_put() and calls subscribe_event_xa_dealloc() with an unset xa_key_level1. subscribe_event_xa_alloc() creates the XA entry exactly once for a given key_level1, on the first occurrence of that key. The unwind path must therefore call subscribe_event_xa_dealloc() exactly once for it as well. Enforce that by adding devx_key_in_sub_list() and calling subscribe_event_xa_dealloc() only when the last matching pending entry is being cleaned up.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74399", "url": "https://ubuntu.com/security/CVE-2026-74399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64544", "url": "https://ubuntu.com/security/CVE-2026-64544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents pefile_digest_pe_contents() computes the trailing-data hash length as pelen - (hashed_bytes + certs_size). A crafted PE can make the addition exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB. This is passed to crypto_shash_update() which reads out of bounds and panics on unmapped vmalloc guard pages. BUG: unable to handle page fault for address: ffffc900038d8000 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152) Call Trace: __sha256_update (lib/crypto/sha256.c:208) crypto_sha256_update (crypto/sha256.c:142) verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436) kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151) __do_sys_kexec_file_load (kernel/kexec_file.c:406) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Validate that the addition does not overflow and the result does not exceed pelen before the subtraction. Return -ELIBBAD on failure.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74402", "url": "https://ubuntu.com/security/CVE-2026-74402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix blocking and non-blocking rng logic The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74408", "url": "https://ubuntu.com/security/CVE-2026-74408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: fix OOB access from firmware tx status queue ID ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74410", "url": "https://ubuntu.com/security/CVE-2026-74410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478), causing an out-of-bounds read from the pre-allocated DMA buffer when skb_put_data copies new_len bytes. The USB transport already validates this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the PCIe path does not. Add a check that new_len does not exceed the DMA buffer size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74416", "url": "https://ubuntu.com/security/CVE-2026-74416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix memory leak in radeon_ring_restore() on lock failure radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74424", "url": "https://ubuntu.com/security/CVE-2026-74424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix NULL pointer dereference for a console without vc_data fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data. Keep fb_display[i].mode set only while the console has a vc_data. Check vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74426", "url": "https://ubuntu.com/security/CVE-2026-74426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: fix NULL pointer dereference in afs_get_tree() afs_alloc_sbi() uses kzalloc for memory allocation. And, if ctx->dyn_root is not null, as->cell and as->volume are null. In trace_afs_get_tree() they are dereferenced. KASAN error message: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550 include/trace/events/afs.h:1365 Call Trace: trace_afs_get_tree include/trace/events/afs.h:1365 [inline] afs_get_tree+0x922/0x1350 fs/afs/super.c:599 vfs_get_tree+0x8e/0x300 fs/super.c:1572 do_new_mount fs/namespace.c:3011 [inline] path_mount+0x14a5/0x2220 fs/namespace.c:3341 do_mount fs/namespace.c:3354 [inline] __do_sys_mount fs/namespace.c:3562 [inline] __se_sys_mount fs/namespace.c:3539 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3539 do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74438", "url": "https://ubuntu.com/security/CVE-2026-74438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun4i-ss - Remove insecure and unused rng_alg Remove sun4i_ss_rng, as it is insecure and unused: - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing locking and has a buffer overflow. sun4i_ss_prng_generate() fails to fill the entire buffer with cryptographic random bytes, because it rounds the destination length down and also doesn't actually wait for the hardware to be ready before pulling bytes from it. - No user of this code is known. It's usable only theoretically via the \"rng\" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen and discovered by Atuin - Automated Vulnerability Discovery Engine There's no point in fixing all these vulnerabilities individually when this is unused code, so let's just remove it.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74578", "url": "https://ubuntu.com/security/CVE-2026-74578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_skcipher - force synchronous processing on trees without ctx->state The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx->iv directly into the skcipher request. After io_submit() the socket lock is dropped and the request is processed asynchronously, so a concurrent sendmsg(ALG_SET_IV) can overwrite ctx->iv and make the in-flight request run under an attacker-controlled IV. For CTR/stream modes this is IV/keystream reuse and lets an unprivileged user recover the plaintext of a concurrent operation. Snapshotting ctx->iv into per-request storage for the async path is not sufficient. For ciphers with statesize == 0 - which includes cbc and ctr - the MSG_MORE inter-chunk IV chaining is carried solely by the in-place req->iv writeback, which a snapshot redirects into per-request memory that af_alg_free_resources() releases on completion, silently producing wrong output. Writing the IV back from the completion callback instead is not possible either: that would require lock_sock() there, but the callback can run in softirq/atomic context, so it must not sleep. Make the operation synchronous instead, which removes both the IV race and any writeback race. This is equivalent to the upstream resolution, commit fcc77d33a34c (\"net: Remove support for AIO on sockets\"), which removed the AIO socket path across net/ entirely and so produces the same end state for this file. This patch deviates from that commit deliberately: rather than removing AIO socket support tree-wide, which would be far too invasive for stable, it removes only the AIO branch in crypto/algif_skcipher.c. io_submit() now completes synchronously; AF_ALG async is rarely used in practice. The -EIOCBQUEUED check in skcipher_recvmsg() is now dead but harmless, and is left alone to keep the fix minimal. Tested on 6.6.y: attacker IV injection dropped from 2296/200000 to 0/200000 after the change; MSG_MORE chunked CTR output bit-identical to single-shot.", "cve_priority": "medium", "cve_public_date": "2026-08-16 09:16:00 UTC" }, { "cve": "CVE-2026-64600", "url": "https://ubuntu.com/security/CVE-2026-64600", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.", "cve_priority": "medium", "cve_public_date": "2026-07-23 06:16:00 UTC" }, { "cve": "CVE-2026-64187", "url": "https://ubuntu.com/security/CVE-2026-64187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fail recovery on a committed log item with no regions If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367)", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64266", "url": "https://ubuntu.com/security/CVE-2026-64266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before returning from fuse_ref_folio() fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues. Fix this by locking the request in fuse_ref_folio() before returning.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64268", "url": "https://ubuntu.com/security/CVE-2026-64268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64269", "url": "https://ubuntu.com/security/CVE-2026-64269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64271", "url": "https://ubuntu.com/security/CVE-2026-64271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: touchwin - reset the packet index on every complete packet tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: \ttw->data[tw->idx++] = data; \tif (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { \t\t... \t\ttw->idx = 0; \t} The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64273", "url": "https://ubuntu.com/security/CVE-2026-64273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - bound the device-reported force-feedback effect index iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: \ti = data[1] & 0x7f; \tif (data[1] & 0x80) { \t\tif (!test_and_set_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) \t\t\t... \t} else if (test_and_clear_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) { \t\t... \t} The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate \"effect started/stopped\" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64274", "url": "https://ubuntu.com/security/CVE-2026-64274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: goodix - clamp the device-reported contact count goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer \tu8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: \tts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64275", "url": "https://ubuntu.com/security/CVE-2026-64275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: elan_i2c - prevent division by zero and arithmetic underflow The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64276", "url": "https://ubuntu.com/security/CVE-2026-64276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64277", "url": "https://ubuntu.com/security/CVE-2026-64277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64279", "url": "https://ubuntu.com/security/CVE-2026-64279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter deregistration race Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name).", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64604", "url": "https://ubuntu.com/security/CVE-2026-64604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f No functional change intended.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64296", "url": "https://ubuntu.com/security/CVE-2026-64296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: \tif (++order == 2) \t\tuniname = p_uniname->name; \telse \t\tuniname += EXFAT_FILE_NAME_LEN; \tlen = exfat_extract_uni_name(ep, entry_uniname); \tname_len += len; \tunichar = *(uniname+len); \t*(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba (\"exfat: check if filename entries exceeds max filename length\")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64298", "url": "https://ubuntu.com/security/CVE-2026-64298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: include MAY_WRITE in open permission mask for O_TRUNC POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64299", "url": "https://ubuntu.com/security/CVE-2026-64299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64303", "url": "https://ubuntu.com/security/CVE-2026-64303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64306", "url": "https://ubuntu.com/security/CVE-2026-64306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: drbg - Fix returning success on failure in CTR_DRBG drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64312", "url": "https://ubuntu.com/security/CVE-2026-64312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64313", "url": "https://ubuntu.com/security/CVE-2026-64313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ecc - Fix carry overflow in vli multiplication The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows. The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow. When commit 3c4b23901a0c (\"crypto: ecdh - Add ECDH software support\") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation. Add proper handling for this boundary by accounting for the carry from the lower addition.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64315", "url": "https://ubuntu.com/security/CVE-2026-64315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64316", "url": "https://ubuntu.com/security/CVE-2026-64316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64317", "url": "https://ubuntu.com/security/CVE-2026-64317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge \"SL\" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64318", "url": "https://ubuntu.com/security/CVE-2026-64318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: aix: bound the pp_count scan to the ppe array aix_partition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array: \tint numpps = be16_to_cpu(pvd->pp_count); \t... \tfor (i = 0; i < numpps; i += 1) { \t\tstruct ppe *p = pvd->ppe + i; \t\t... \t\tlp_ix = be16_to_cpu(p->lp_ix); pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk pp_count. pp_count is an unvalidated __be16 read straight from the descriptor, so a crafted AIX image with pp_count larger than 1016 drives the loop to read pvd->ppe[i] past the end of the allocation (up to 65535 entries, ~2 MB out of bounds). The partition scan runs without mounting anything, when a block device with a crafted AIX/IBM partition table appears (an attacker-supplied image attached with losetup -P, or a device auto-scanned by udev), via msdos_partition() -> aix_partition(). Clamp the scan to the number of entries the ppe[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64322", "url": "https://ubuntu.com/security/CVE-2026-64322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when \tsizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: \tfor (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) { \t\tstruct sparingEntry *entry = &st->mapEntry[i]; \t\t... entry->origLocation ... \t} in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64323", "url": "https://ubuntu.com/security/CVE-2026-64323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate VAT header length against the VAT inode size udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size: \tmap->s_type_specific.s_virtual.s_start_offset = \t\tle16_to_cpu(vat20->lengthHeader); \tmap->s_type_specific.s_virtual.s_num_entries = \t\t(sbi->s_vat_inode->i_size - \t\t\tmap->s_type_specific.s_virtual.s_start_offset) >> 2; lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the \"block > s_num_entries\" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads \t((__le32 *)(iinfo->i_data + s_start_offset))[block] so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read. Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64324", "url": "https://ubuntu.com/security/CVE-2026-64324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate free block extents against the partition length udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64330", "url": "https://ubuntu.com/security/CVE-2026-64330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64331", "url": "https://ubuntu.com/security/CVE-2026-64331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running `usbip attach` from the host would cause the guest to oops with the following backtrace: Call trace: vep_dequeue+0x1c/0xe4 (P) usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34 __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64332", "url": "https://ubuntu.com/security/CVE-2026-64332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ulpi: fix memory leak on registration failure The allocated device name is never freed on early ULPI device registration failures. Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64333", "url": "https://ubuntu.com/security/CVE-2026-64333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64334", "url": "https://ubuntu.com/security/CVE-2026-64334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix hard lockup on disconnect If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled. Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect. This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64335", "url": "https://ubuntu.com/security/CVE-2026-64335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix broken rx after throttle If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound). Clear the throttle flags and submit the urb if needed when opening the port.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64336", "url": "https://ubuntu.com/security/CVE-2026-64336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan_pda: fix information leak The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspan_pda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer. Fix the information leak by making sure that keyspan_pda_write_start() returns zero on success as intended.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64337", "url": "https://ubuntu.com/security/CVE-2026-64337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: unmap request DMA on queue failure mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails. Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64338", "url": "https://ubuntu.com/security/CVE-2026-64338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: misc: uss720: unregister parport on probe failure uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered. Leaving the port registered is more than a private allocation leak: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is about to release. Undo the pre-announce registration in the get_1284_register() failure branch before jumping to the common private-data cleanup path. Clear priv->pp first, matching the disconnect path and avoiding a stale pointer in the private data. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64340", "url": "https://ubuntu.com/security/CVE-2026-64340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: legousbtower: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64342", "url": "https://ubuntu.com/security/CVE-2026-64342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: iowarrior: fix use-after-free on disconnect Submitted write URBs are not stopped on close() and therefore need to be stopped unconditionally on disconnect() to avoid use-after-free in the completion handler.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64343", "url": "https://ubuntu.com/security/CVE-2026-64343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ldusb: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64344", "url": "https://ubuntu.com/security/CVE-2026-64344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64346", "url": "https://ubuntu.com/security/CVE-2026-64346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: Fix use-after-free in gadget_match_driver The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usb_del_gadget() frees the udc memory (e.g., via mode-switch work) while gadget_match_driver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed: [39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr : gadget_match_driver+0x34/0x60 ... [39430.911890][ T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][ T1171] Workqueue: events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usb_gadget_release() routine to the core. When the gadget is added, usb_add_gadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usb_gadget_release() drops the reference to the udc and then calls the gadget's release routine.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64347", "url": "https://ubuntu.com/security/CVE-2026-64347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler The OTG branch of composite_setup() falls back to the first configuration when none is selected: \tif (cdev->config) \t\tconfig = cdev->config; \telse \t\tconfig = list_first_entry(&cdev->configs, \t\t\t\t\t struct usb_configuration, list); \tif (!config) \t\tgoto done; \t... \tmemcpy(req->buf, config->descriptors[0], value); list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the \"if (!config)\" check is dead. When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer. cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch. Use list_first_entry_or_null() so the existing check does its job.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64350", "url": "https://ubuntu.com/security/CVE-2026-64350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info() cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and stream_rings array, but leaves stream_ctx_array allocated. Free the stream context array before falling through to the stream_rings cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64351", "url": "https://ubuntu.com/security/CVE-2026-64351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: bound RX frame length in kalmia_rx_fixup() kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usb_packet_length to about 65530. That bypasses the usb_packet_length < ether_packet_length truncation path. The device-supplied ether_packet_length, a le16 up to 65535 read from header_start[2], then drives a memcmp() and the following skb_trim() and skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10, which is 14000 bytes. That is an out of bounds read. Require both the start and end framing headers to be present before subtracting them, on every loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64359", "url": "https://ubuntu.com/security/CVE-2026-64359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64360", "url": "https://ubuntu.com/security/CVE-2026-64360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64362", "url": "https://ubuntu.com/security/CVE-2026-64362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: lg-g15: cancel pending work on remove to fix a use-after-free lg_g15_data is allocated with devm and holds a work item. The report handlers schedule that work straight from device input. lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key, and lg_g510_leds_event() does it too. The worker dereferences the lg_g15_data back through container_of. The driver had no remove callback and never cancelled the work. So if a report scheduled the work and the keyboard was then unplugged, devres freed lg_g15_data while the work was still pending or running, and the worker touched freed memory. This is a use-after-free. It is reachable as a race on device unplug. Add a remove callback that cancels the work before devres frees the state. g15->work is only initialized for the models that schedule it (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the cancel on g15->work.func to avoid cancelling a work that was never set up. The g15 NULL test mirrors the one already in lg_g15_raw_event().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68091", "url": "https://ubuntu.com/security/CVE-2026-68091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: stop hardware after post-start probe failures wacom_parse_and_register() starts HID hardware before registering inputs and initializing pad LEDs/remotes. Those later steps can fail, but their error paths currently release Wacom resources without stopping the HID hardware. Route post-hid_hw_start() failures through hid_hw_stop() before releasing driver resources. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64370", "url": "https://ubuntu.com/security/CVE-2026-64370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference via get_pid() and stores it in timer.it.cpu.pid. If the subsequent posix_cpu_timer_set() call fails, the function returns immediately without calling posix_cpu_timer_del() to release the pid reference, causing a leak. Fix it by calling posix_cpu_timer_del() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64372", "url": "https://ubuntu.com/security/CVE-2026-64372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: pcc: fix use-after-free and double free in _OSC evaluation pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the two-phase _OSC negotiation. Between the two calls it freed output.pointer but left output.length unchanged. Since acpi_evaluate_object() treats a non-zero length with a non-NULL pointer as an existing buffer to write into, the second call wrote into freed memory (use-after-free). The subsequent kfree(output.pointer) at out_free then freed the same pointer a second time (double free). Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first result, so ACPICA allocates a fresh buffer for each phase independently.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64373", "url": "https://ubuntu.com/security/CVE-2026-64373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path. Unlike the normal system suspend path, the reboot path does not call freeze_processes(), so userspace processes and kernel threads remain active. This allows CPU hotplug operations to run concurrently with cpufreq_suspend(). The original code has no synchronization with CPU hotplug, leading to a race condition where governor_data can be freed by the hotplug path while cpufreq_suspend() is still accessing it, resulting in a null pointer dereference: Unable to handle kernel NULL pointer dereference Call Trace: do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200 Fix this by adding cpus_read_lock()/cpus_read_unlock() to cpufreq_suspend() to block CPU hotplug operations while suspend is in progress. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64374", "url": "https://ubuntu.com/security/CVE-2026-64374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64403", "url": "https://ubuntu.com/security/CVE-2026-64403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64408", "url": "https://ubuntu.com/security/CVE-2026-64408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: pin L2CAP connection during netdev registration bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64411", "url": "https://ubuntu.com/security/CVE-2026-64411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: terminate table name before find_table_lock() update_counters() and compat_update_counters() forward a user-supplied 32-byte table name to find_table_lock() without NUL-terminating it. On a lookup miss, find_inlist_lock() calls try_then_request_module(..., \"%s%s\", \"ebtable_\", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte. BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) __request_module (kernel/module/kmod.c:150) do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) update_counters (net/bridge/netfilter/ebtables.c:1440) do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573) nf_setsockopt (net/netfilter/nf_sockopt.c:101) ip_setsockopt (net/ipv4/ip_sockglue.c:1424) raw_setsockopt (net/ipv4/raw.c:847) __sys_setsockopt (net/socket.c:2393) ... compat_do_replace() shares the same unterminated name via compat_copy_ebt_replace_from_user(); terminate it there too so all find_table_lock() callers behave alike. The other callers already terminate the name after the copy.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64412", "url": "https://ubuntu.com/security/CVE-2026-64412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: module names must be null-terminated We need to explicitly check the length, else we may pass non-null terminated string to request_module().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64420", "url": "https://ubuntu.com/security/CVE-2026-64420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: cros_ec: Delay dev_set_drvdata() until probe success If ec_device_probe() fails, cros_ec_class_release releases memory for the cros_ec_dev structure. However, because the drvdata was already set, sub-drivers like cros_ec_typec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when cros_ec_typec attempts to access &typec->ec->ec->dev on a device that has already been released. Move dev_set_drvdata() to ensure that the pointer is only made available once all initialization steps have succeeded. sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' Call trace: sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... BUG: KASAN: invalid-access in __memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOT_MODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: events_unbound deferred_probe_work_func Call trace: __memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64422", "url": "https://ubuntu.com/security/CVE-2026-64422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP socket state. The sysctl is stored as an `int` but copied into the `u32` `tp->reordering` field for new sockets, so negative writes wrap to large values. With `tcp_mtu_probing=2`, the wrapped value can overflow the `tcp_mtu_probe()` size calculation and drive the MTU probing path into an out-of-bounds read. Route `tcp_reordering` writes through `proc_dointvec_minmax()` and require it to be at least 1. Also require `tcp_max_reordering` to be at least 1 so the configured maximum cannot become negative either. When registering the table for a non-init network namespace, relocate `extra2` pointers that refer into `init_net.ipv4` so the `tcp_reordering` upper bound follows that namespace's `tcp_max_reordering`. Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`. This keeps the send queue and window checks from being bypassed through signed integer overflow.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64423", "url": "https://ubuntu.com/security/CVE-2026-64423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: remove multicast group from hash table on device destruction When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through the multicast list and calls ip_ma_put() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mc_hash). Since the device remains published in dev->ip_ptr until after ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs. Fix this by unlinking the multicast group from mc_hash using ip_mc_hash_remove() before scheduling it for reclamation. BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276 Call Trace: dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 Allocated by task 2239: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40 __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300 Freed by task 0: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50 __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64425", "url": "https://ubuntu.com/security/CVE-2026-64425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 10dc95939817 (\"io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64429", "url": "https://ubuntu.com/security/CVE-2026-64429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: eic-sprd: use raw_spinlock_t in the irq startup path sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64430", "url": "https://ubuntu.com/security/CVE-2026-64430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid calling pci_irq_vector() from hardirq context ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive the vector number. pci_irq_vector() calls msi_get_virq() that takes a mutex and can therefore trigger \"scheduling while atomic\" splats: BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedule_preempt_disabled+0x28/0x50 __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf] __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64432", "url": "https://ubuntu.com/security/CVE-2026-64432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns In the analysis pass of $LogFile journal replay, log_replay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcns_follow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time: BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array: 1. dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow. 2. lrh->target_vcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge size_t. Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL. This mirrors the bounds-check pattern added in commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") and commit 0ca0485e4b2e (\"fs/ntfs3: validate rec->used in journal-replay file record check\").", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68090", "url": "https://ubuntu.com/security/CVE-2026-68090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) \treturn; obj = alloc(); \t\t\t\tif (!obj) { \t\t\t\t\t\t\t// Out of memory \tdebug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized \tif (!IS_ERR_OR_NULL(obj)) \treturn; if (!obj) { \tdebug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64435", "url": "https://ubuntu.com/security/CVE-2026-64435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: Fix data races of skb_queue_len() readers on audit_queue Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races. All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn() KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 value changed: 0x00000001 -> 0x00000000 ================================================================== Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side. [PM: line length tweak]", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64436", "url": "https://ubuntu.com/security/CVE-2026-64436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: initialize alg_key_len for IPComp states pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name: \tx->calg = kmalloc_obj(*x->calg); \tif (!x->calg) { \t\terr = -ENOMEM; \t\tgoto out; \t} \tstrcpy(x->calg->alg_name, a->name); \tx->props.calgo = sa->sadb_sa_encrypt; Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data. calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE: \txfrm_state_migrate() \t xfrm_state_clone_and_setup() \t x->calg = xfrm_algo_clone(orig->calg); \t kmemdup(orig, xfrm_alg_len(orig)); where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0): BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90 ___sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4) Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail. The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent. Initialize calg->alg_key_len to 0, matching the aalg/ealg branches.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64599", "url": "https://ubuntu.com/security/CVE-2026-64599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: amlogic - avoid double cleanup in meson_crypto_probe() When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker(). Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM. ================================================================== BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0 Read of size 8 at addr ff1100010c057a68 by task insmod/265 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? kthread_destroy_worker+0xb2/0xd0 ? kthread_destroy_worker+0xb2/0xd0 kasan_report+0xca/0x100 ? kthread_destroy_worker+0xb2/0xd0 kthread_destroy_worker+0xb2/0xd0 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto] platform_probe+0x99/0x140 really_probe+0x1c6/0x6a0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x248/0x310 ? acpi_driver_match_device+0xb0/0x100 driver_probe_device+0x48/0x210 ? __pfx___device_attach_driver+0x10/0x10 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x104/0x190 ? __pfx_bus_for_each_drv+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 __device_attach+0x19d/0x3b0 ? __pfx___device_attach+0x10/0x10 ? do_raw_spin_unlock+0x53/0x220 device_initial_probe+0x78/0xa0 bus_probe_device+0x5b/0x130 device_add+0xcfd/0x1430 ? __pfx_device_add+0x10/0x10 ? insert_resource+0x34/0x50 ? lock_release+0xc9/0x290 platform_device_add+0x24e/0x590 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro] meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro] do_one_initcall+0xc0/0x450 ? __pfx_do_one_initcall+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 ? __create_object+0x59/0x80 ? kasan_unpoison+0x27/0x60 do_init_module+0x27b/0x7d0 ? __pfx_do_init_module+0x10/0x10 ? kasan_quarantine_put+0x84/0x1d0 ? kfree+0x32c/0x510 ? load_module+0x561e/0x5ff0 load_module+0x54fe/0x5ff0 ? __pfx_load_module+0x10/0x10 ? security_file_permission+0x20/0x40 ? kernel_read_file+0x23d/0x6e0 ? mmap_region+0x235/0x4a0 ? __pfx_kernel_read_file+0x10/0x10 ? __file_has_perm+0x2c0/0x3e0 init_module_from_file+0x158/0x180 ? __pfx_init_module_from_file+0x10/0x10 ? __lock_acquire+0x45a/0x1ba0 ? idempotent_init_module+0x315/0x610 ? lock_release+0xc9/0x290 ? lock ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64440", "url": "https://ubuntu.com/security/CVE-2026-64440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB write in HT_caps_handler() HT_caps_handler() iterates pIE->length bytes and writes into HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct HT_caps_element). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlme_ext_info. Truncate the iteration count to the size of HT_caps.u.HT_cap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HT_caps_enable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64536", "url": "https://ubuntu.com/security/CVE-2026-64536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop The loop in is_ap_in_tkip() iterates over IEs without verifying that enough bytes remain before dereferencing the IE header or its payload: - pIE->element_id and pIE->length are read without checking that i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the buffer causes an OOB read. - For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12, which requires pIE->length >= 16. For WLAN_EID_RSN it compares pIE->data + 8, requiring pIE->length >= 12. Neither requirement is checked. Add the missing IE header and payload bounds checks and guard each data access with an explicit pIE->length minimum, matching the pattern established in update_beacon_info().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-64442", "url": "https://ubuntu.com/security/CVE-2026-64442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64443", "url": "https://ubuntu.com/security/CVE-2026-64443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the element_id byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64444", "url": "https://ubuntu.com/security/CVE-2026-64444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i < pkt_len. When a malicious AP sends an AssocResponse whose last IE has only one byte remaining in the frame (the element_id byte lands at pkt_len-1), the loop reads pIE->length from pframe[pkt_len], which is one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pkt_len, silently passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pkt_len.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64445", "url": "https://ubuntu.com/security/CVE-2026-64445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth() OnAuth() has two bugs in the shared-key authentication path. When the Privacy bit is set, rtw_wep_decrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtw_wep_decrypt(), length is computed as: length = len - WLAN_HDR_A3_LEN - iv_len and then passed as (length - 4) to crc32_le(). If len is less than WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative and, after the implicit cast to size_t, causes crc32_le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path. When processing a seq=3 response, rtw_get_ie() stores the Challenge Text IE length in ie_len, but the subsequent memcmp() always reads 128 bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64450", "url": "https://ubuntu.com/security/CVE-2026-64450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it (\"if (glen > dlen) break;\"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: \tthis_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), \t\t\t GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: \"if (glen > dlen) break;\" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means \"legacy peer without Selective ACK\", a distinct legitimate state.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64452", "url": "https://ubuntu.com/security/CVE-2026-64452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix NHC entry use-after-free on error path lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding lowpan_nhc_lock. If the descriptor has no uncompress callback, the error path drops the lock before printing nhc->name. lowpan_nhc_del() removes descriptors under the same lock and then relies on synchronize_net() before the owning module can be unloaded. That only waits for net RX RCU readers. lowpan_header_decompress() is also exported and can be reached from callers that are not necessarily covered by the net core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive path. This leaves a race where one task drops lowpan_nhc_lock in the error path, another task unregisters and frees the matching descriptor after synchronize_net() returns, and the first task then dereferences nhc->name for the warning. With the post-unlock window widened, KASAN reports: BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220 Read of size 8 lowpan_nhc_do_uncompression lowpan_header_decompress Fix this by printing the warning before dropping lowpan_nhc_lock, so the descriptor name is read while unregister is still excluded. The malformed packet is still rejected with -ENOTSUPP.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64454", "url": "https://ubuntu.com/security/CVE-2026-64454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: run gadget disconnect from sleepable suspend context dwc3_gadget_suspend() takes dwc->lock with IRQs disabled and then calls dwc3_disconnect_gadget(). For async callbacks that helper only uses plain spin_unlock()/spin_lock(), so the gadget ->disconnect() callback still runs with IRQs disabled and any sleepable callback trips Lockdep. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the dwc3_gadget_suspend() -> dwc3_disconnect_gadget() -> gadget_driver->disconnect() chain, and Lockdep reported: BUG: sleeping function called from invalid context gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] Keep the disconnect callback selection in one common helper, but add a sleepable suspend-side wrapper which snapshots the callback under dwc->lock and then runs it after spin_unlock_irqrestore(). The regular event path still uses the existing spin_unlock()/spin_lock() window.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64455", "url": "https://ubuntu.com/security/CVE-2026-64455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: chaoskey: Fix slab-use-after-free in chaoskey_release() The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: \tBUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) \tRead of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 \tHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 \tCall Trace: \t \t dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) \t print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) \t kasan_report (mm/kasan/report.c:595) \t dev_driver_string (drivers/base/core.c:2406) \t __dynamic_dev_dbg (lib/dynamic_debug.c:906) \t chaoskey_release (drivers/usb/misc/chaoskey.c:323) \t __fput (fs/file_table.c:510) \t fput_close_sync (fs/file_table.c:615) \t __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) \t do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) \t entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64456", "url": "https://ubuntu.com/security/CVE-2026-64456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: virtio: clamp device-reported used.len at copy_data() random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64189", "url": "https://ubuntu.com/security/CVE-2026-64189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64465", "url": "https://ubuntu.com/security/CVE-2026-64465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix sleep in atomic context in xhci_free_streams() When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64468", "url": "https://ubuntu.com/security/CVE-2026-64468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_free_transaction() In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64469", "url": "https://ubuntu.com/security/CVE-2026-64469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_thread_release() When a thread exits, binder_thread_release() walks its transaction stack to clear the t->from and t->to_proc that correspond with the exiting thread. However, a process dying in parallel might attempt to kfree some of these transactions. And if one of them has no associated t->to_proc, the t->to_proc->inner_lock will not be acquired. This means that transaction accesses in binder_thread_release() after t->to_proc has been cleared might race with binder_free_transaction() and cause a use-after-free error as reported by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798 Write of size 8 at addr ffff000016627500 by task X/715 CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...] Allocated by task 717 on cpu 18 at 67.267803s: __kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+0x554/0x8150 binder_thread_write+0xa30/0x4354 binder_ioctl+0x20f0/0x299c [...] Freed by task 202 on cpu 18 at 90.416221s: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_free_transaction+0x150/0x294 binder_send_failed_reply+0x398/0x6d8 binder_release_work+0x3e4/0x4ec binder_deferred_func+0xbd8/0x104c [...] ================================================================== In order to avoid this, make sure that binder_free_transaction() reads the t->to_proc under the transaction lock. This will serialize the transaction release with the accesses in binder_thread_release(). Plus, it matches the documented locking rules for @to_proc.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64470", "url": "https://ubuntu.com/security/CVE-2026-64470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on marvell probe failure Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64471", "url": "https://ubuntu.com/security/CVE-2026-64471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on registration failure Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64478", "url": "https://ubuntu.com/security/CVE-2026-64478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64483", "url": "https://ubuntu.com/security/CVE-2026-64483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. \tcount = be32_to_cpu(payload->sample_count); \tif (likely(count <= (length - 16) / 4)) \t\tisight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64484", "url": "https://ubuntu.com/security/CVE-2026-64484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es1938: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. snd_es1938_mixer() does not check the return value before dereferencing the pointer, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64487", "url": "https://ubuntu.com/security/CVE-2026-64487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every iteration it advances buf and subtracts the block size while looping on \"while (len)\". len is urb->actual_length. That value is supplied by the device and is not guaranteed to be a multiple of 16. When a final short block leaves len between 1 and 15, the loop runs once more, reads up to buf[15], and then does \"len -= TKS4_MSGBLOCK_SIZE\". As len is unsigned this underflows to a huge value. The loop then keeps iterating and walking buf far past the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus block id happens to be hit. Iterate only while a full message block is available. This stops the unsigned underflow and silently drops any trailing partial block, which carries no complete control value anyway. The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1 and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor urb->actual_length before dispatching.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64494", "url": "https://ubuntu.com/security/CVE-2026-64494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: fix runtime PM leak on read error gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the \"out\" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a \"goto out\" to ensure the reference is properly dropped on the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64495", "url": "https://ubuntu.com/security/CVE-2026-64495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: bmg160: bail out when bandwidth/filter is not in table bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: \tfor (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { \t\tif (bmg160_samp_freq_table[i].bw_bits == bw_bits) \t\t\tbreak; \t} \t*val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64496", "url": "https://ubuntu.com/security/CVE-2026-64496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64497", "url": "https://ubuntu.com/security/CVE-2026-64497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64602", "url": "https://ubuntu.com/security/CVE-2026-64602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: spear: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in spear_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, spear_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ spear_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64500", "url": "https://ubuntu.com/security/CVE-2026-64500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: lpc32xx: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64503", "url": "https://ubuntu.com/security/CVE-2026-64503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64504", "url": "https://ubuntu.com/security/CVE-2026-64504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer \tu16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: \tcount = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: \tif (samples && count > samples) \t\tcount = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: \tbmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64505", "url": "https://ubuntu.com/security/CVE-2026-64505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check for header Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68088", "url": "https://ubuntu.com/security/CVE-2026-68088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check to response query Add variable representations for BufLength and BufOffset in rndis_query_response(), and perform a length check on them. This is identical to how rndis_set_response() handles these parameters.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-53392", "url": "https://ubuntu.com/security/CVE-2026-53392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53402", "url": "https://ubuntu.com/security/CVE-2026-53402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font() When fbcon_do_set_font() fails (e.g., due to a memory allocation failure inside vc_resize() under heavy memory pressure), it jumps to the `err_out` label to roll back the console state. However, the current rollback logic forgets to restore the `hi_font` state, leading to a severe state machine corruption. Earlier in the function, `set_vc_hi_font()` might be called to change `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()` subsequently fails, the `err_out` path restores `vc_font.charcount` but entirely skips rolling back the `vc_hi_font_mask` and the screen buffer. This mismatch leaves the terminal in a desynchronized state. Because `vc_hi_font_mask` remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure. Fix this by adding the missing rollback logic for the `hi_font` mask and screen buffer in the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63810", "url": "https://ubuntu.com/security/CVE-2026-63810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Avoid mounting the bdev pseudo-filesystem in userspace The bdev pseudo-filesystem is an internal kernel filesystem with which userspace should not interfere. Unregister it so that userspace cannot even attempt to mount it. This fixes a bug [1] that occurs when attempting to access files, because the system call move_mount() uses pointers declared in the inode_operations structure, which for the bdev pseudo-filesystem are always equal to 0. `inode->i_op = &empty_iops;` [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:0x0 Call Trace: lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460 open_last_lookups fs/namei.c:3550 [inline] path_openat+0x953/0x2700 fs/namei.c:3780 do_filp_open+0x1c5/0x410 fs/namei.c:3810 do_sys_openat2+0x171/0x4d0 fs/open.c:1318 do_sys_open fs/open.c:1334 [inline] __do_sys_openat fs/open.c:1350 [inline] __se_sys_openat fs/open.c:1345 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68459", "url": "https://ubuntu.com/security/CVE-2026-68459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs() When we mount device w/ gc_merge mount option, we may suffer below potential deadlock: Kworker\t\t\t\t\tGC trehad\t\t\tTruncator - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback --- set writeback flag on folio - f2fs_outplace_write_data : cached folio in internal bio cache - f2fs_balance_fs - wake_up(gc_thread) : wake up gc thread to run foreground GC - finish_wait(fggc_wq) : wait on the waitqueue --- wait on GC thread to finish the work \t\t\t\t\t\t\t\t\t- truncate_inode_pages_range \t\t\t\t\t\t\t\t\t - __filemap_get_folio(, FGP_LOCK) --- lock folio \t\t\t\t\t\t\t\t\t - truncate_inode_partial_folio \t\t\t\t\t\t\t\t\t - folio_wait_writeback --- wait on writeback being cleared \t\t\t\t\t- do_garbage_collect \t\t\t\t\t - move_data_page \t\t\t\t\t - f2fs_get_lock_data_folio \t\t\t\t\t - lock on folio --- blocked on folio's lock In order to avoid such deadlock, let's call below functions to commit cached bios in GC_MERGE path of f2fs_balance_fs() as the same as we did in NOGC_MERGE path. - f2fs_submit_merged_write(sbi, DATA); - f2fs_submit_all_merged_ipu_writes(sbi);", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-68460", "url": "https://ubuntu.com/security/CVE-2026-68460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in f2fs_balance_fs() When the f2fs filesystem space is nearly exhausted, we encounter deadlock issues as below: INFO: task A:1890 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:A state:D stack:0 pid:1890 tgid:1626 ppid:1153 flags:0x00000204 Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 folio_wait_bit+0x20/0x38 folio_wait_writeback+0x54/0xc8 truncate_inode_partial_folio+0x70/0x1e0 truncate_inode_pages_range+0x1b0/0x450 truncate_pagecache+0x54/0x88 f2fs_file_write_iter+0x3e8/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task kworker/u8:11:2680853 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:11 state:D stack:0 pid:2680853 tgid:2680853 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 __filemap_get_folio+0x214/0x348 pagecache_get_page+0x20/0x70 f2fs_get_read_data_page+0x150/0x3e8 f2fs_get_lock_data_page+0x2c/0x160 move_data_page+0x50/0x478 do_garbage_collect+0xd38/0x1528 f2fs_gc+0x240/0x7e0 f2fs_balance_fs+0x1a0/0x208 f2fs_write_single_data_page+0x6e4/0x730 f2fs_write_cache_pages+0x378/0x9b0 f2fs_write_data_pages+0x2e4/0x388 do_writepages+0x8c/0x2c8 __writeback_single_inode+0x4c/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x200 INFO: task kworker/u8:8:2641297 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:8 state:D stack:0 pid:2641297 tgid:2641297 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_write_inode+0xf4/0x328 __writeback_single_inode+0x370/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x20 INFO: task B:1902 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:B state:D stack:0 pid:1902 tgid:1626 ppid:1153 flags:0x0000020c Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_map_blocks+0x94c/0x1110 f2fs_file_write_iter+0x228/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task sync:2769849 blocked for more than 120 seconds. Tainted: G ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63815", "url": "https://ubuntu.com/security/CVE-2026-63815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: bound i_inline_xattr_size for non-inline-xattr inodes When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: \tif (f2fs_sb_has_flexible_inline_xattr(sbi)) \t\tfi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: \tMAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) \tNR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) \taddrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: \twhile (bit_pos < d->max)\t\t/* fs/f2fs/dir.c */ \t\t... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ... Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files. Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63818", "url": "https://ubuntu.com/security/CVE-2026-63818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate orphan inode entry count f2fs_recover_orphan_inodes() trusts the orphan block entry_count when replaying orphan inodes from the checkpoint pack. A corrupted entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the ino[] array and interpret footer or following data as inode numbers. On a crafted image, mounting an unpatched kernel can drive orphan recovery into f2fs_bug_on() and panic the kernel. Validate entry_count before consuming entries so corrupted checkpoint data fails the mount with -EFSCORRUPTED and requests fsck instead. Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be recorded in the superblock s_errors[] field. This gives fsck a persistent hint even though mount-time orphan recovery failure may leave no chance to persist SBI_NEED_FSCK through a checkpoint.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68461", "url": "https://ubuntu.com/security/CVE-2026-68461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device property: initialize the remaining fields of fwnode_handle in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitialized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. While at it: initialize the remaining fields of struct fwnode_handle too just to be sure. [ Fix typo in commit message. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63829", "url": "https://ubuntu.com/security/CVE-2026-63829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper. Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs. Commit 8b484efd5cb4 (\"ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\") added the same check on the ioctl path. This adds it on RTM_NEWLINK.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2022-3114", "url": "https://ubuntu.com/security/CVE-2022-3114", "cve_description": "An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference.", "cve_priority": "negligible", "cve_public_date": "2022-12-14 21:15:00 UTC" }, { "cve": "CVE-2026-64514", "url": "https://ubuntu.com/security/CVE-2026-64514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is \"is this fault still WP-blocked?\". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says \"wait\", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns \"don't wait\" and lets the fault path retry.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53399", "url": "https://ubuntu.com/security/CVE-2026-53399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: release layout stid on setlease failure nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "high", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-31451", "url": "https://ubuntu.com/security/CVE-2026-31451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption. The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-43355", "url": "https://ubuntu.com/security/CVE-2026-43355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: bh1780: fix PM runtime leak on error path Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53139", "url": "https://ubuntu.com/security/CVE-2026-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23364", "url": "https://ubuntu.com/security/CVE-2026-23364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Compare MACs in constant time To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-46208", "url": "https://ubuntu.com/security/CVE-2026-46208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2023-54271", "url": "https://ubuntu.com/security/CVE-2023-54271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init blk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This happens because iocg->ioc is NULL. The field is initialized by ioc_pd_init() and never cleared. The NULL deref is caused by blkcg_activate_policy() installing blkg_policy_data before initializing it. blkcg_activate_policy() was doing the following: 1. Allocate pd's for all existing blkg's and install them in blkg->pd[]. 2. Initialize all pd's. 3. Online all pd's. blkcg_activate_policy() only grabs the queue_lock and may release and re-acquire the lock as allocation may need to sleep. ioc_weight_write() grabs blkcg->lock and iterates all its blkg's. The two can race and if ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a pd which is not initialized yet, leading to crash. The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c \"echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos\" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weight with the following patch applied: > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index fc49be622e05..38d671d5e10c 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol) > \t\tpd->online = false; > \t} > > + if (system_state == SYSTEM_RUNNING) { > + spin_unlock_irq(&q->queue_lock); > + ssleep(1); > + spin_lock_irq(&q->queue_lock); > + } > + > \t/* all allocated, init in the same order */ > \tif (pol->pd_init_fn) > \t\tlist_for_each_entry_reverse(blkg, &q->blkg_list, q_node) I don't see a reason why all pd's should be allocated, initialized and onlined together. The only ordering requirement is that parent blkgs to be initialized and onlined before children, which is guaranteed from the walking order. Let's fix the bug by allocating, initializing and onlining pd for each blkg and holding blkcg->lock over initialization and onlining. This ensures that an installed blkg is always fully initialized and onlined removing the the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53189", "url": "https://ubuntu.com/security/CVE-2026-53189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-52918", "url": "https://ubuntu.com/security/CVE-2026-52918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46160", "url": "https://ubuntu.com/security/CVE-2026-46160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix missing last_unlink_trans update when removing a directory When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path \"/mnt/dir1\" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] \t\tinode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] \t\trdev 0 sequence 2 flags 0x0 [445771.638102] \t\tatime 1775744884.0 [445771.660056] \t\tctime 1775744885.645502983 [445771.660058] \t\tmtime 1775744885.645502983 [445771.660060] \t\totime 1775744884.0 [445771.660062] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] \t\tindex 0 name_len 2 [445771.660066] \titem 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] \t\tlocation key (259 1 0) type 2 [445771.660070] \t\ttransid 9 data_len 0 name_len 4 [445771.660075] \titem 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] \t\tlocation key (257 1 0) type 2 [445771.660077] \t\ttransid 9 data_len 0 name_len 4 [445771.660078] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] \t\tlocation key (257 1 0) type 2 [445771.660080] \t\ttransid 9 data_len 0 name_len 4 [445771.660081] \titem 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] \t\tlocation key (259 1 0) type 2 [445771.660083] \t\ttransid 9 data_len 0 name_len 4 [445771.660084] \titem 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] \t\tinode generation 9 transid 9 size 8 nbytes 0 [445771.660087] \t\tblock group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] \t\trdev 0 sequence 2 flags 0x0 [445771.660089] \t\tatime 1775744885.641174097 [445771.660090] \t\tctime 1775744885.645502983 [445771.660091] \t\tmtime 1775744885.645502983 [445771.660105] \t\totime 1775744885.641174097 [445771.660106] \titem 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] \t\tindex 2 name_len 4 [445771.660108] \titem 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] \t\tlocation key (2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46292", "url": "https://ubuntu.com/security/CVE-2026-46292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46159", "url": "https://ubuntu.com/security/CVE-2026-46159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46191", "url": "https://ubuntu.com/security/CVE-2026-46191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46116", "url": "https://ubuntu.com/security/CVE-2026-46116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: \tif (x->km.seq) \t\thlist_del_rcu(&x->byseq); \tif (x->id.spi) \t\thlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46193", "url": "https://ubuntu.com/security/CVE-2026-46193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46180", "url": "https://ubuntu.com/security/CVE-2026-46180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31709", "url": "https://ubuntu.com/security/CVE-2026-31709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-46196", "url": "https://ubuntu.com/security/CVE-2026-46196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46291", "url": "https://ubuntu.com/security/CVE-2026-46291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46090", "url": "https://ubuntu.com/security/CVE-2026-46090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 (\"ALSA: aloop: Fix racy access at PCM trigger\") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46052", "url": "https://ubuntu.com/security/CVE-2026-46052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are unhashed Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume \"negative\" also means \"unhashed\": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45999", "url": "https://ubuntu.com/security/CVE-2026-45999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: \"outpages - inpages\" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46103", "url": "https://ubuntu.com/security/CVE-2026-46103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46056", "url": "https://ubuntu.com/security/CVE-2026-46056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46299", "url": "https://ubuntu.com/security/CVE-2026-46299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: \t========================= \tWARNING: held lock freed! \t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted \t------------------------- \tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! \tffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \t2 locks held by mount/174: \t#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 \t#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \tstack backtrace: \tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tCall Trace: \t \tdump_stack_lvl+0x82/0xd0 \tdebug_check_no_locks_freed+0x13a/0x180 \tkfree+0x16b/0x510 \t? hfsplus_fill_super+0xcb4/0x18a0 \thfsplus_fill_super+0xcb4/0x18a0 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x65f/0xc30 \t? srso_return_thunk+0x5/0x5f \t? pointer+0x4ce/0xbf0 \t? trace_contention_end+0x11c/0x150 \t? __pfx_pointer+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x79b/0xc30 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? vsnprintf+0x6da/0x1270 \t? srso_return_thunk+0x5/0x5f \t? __mutex_unlock_slowpath+0x157/0x740 \t? __pfx_vsnprintf+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? mark_held_locks+0x49/0x80 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? irqentry_exit+0x17b/0x5e0 \t? trace_irq_disable.constprop.0+0x116/0x150 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? __pfx_hfsplus_fill_super+0x10/0x10 \tget_tree_bdev_flags+0x302/0x580 \t? __pfx_get_tree_bdev_flags+0x10/0x10 \t? vfs_parse_fs_qstr+0x129/0x1a0 \t? __pfx_vfs_parse_fs_qstr+0x3/0x10 \tvfs_get_tree+0x89/0x320 \tfc_mount+0x10/0x1d0 \tpath_mount+0x5c5/0x21c0 \t? __pfx_path_mount+0x10/0x10 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? kmem_cache_free+0x307/0x540 \t? user_path_at+0x51/0x60 \t? __x64_sys_mount+0x212/0x280 \t? srso_return_thunk+0x5/0x5f \t__x64_sys_mount+0x212/0x280 \t? __pfx___x64_sys_mount+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \tdo_syscall_64+0x111/0x680 \tentry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7ffacad55eae \tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 \tRSP: 002b ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46169", "url": "https://ubuntu.com/security/CVE-2026-46169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45991", "url": "https://ubuntu.com/security/CVE-2026-45991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46065", "url": "https://ubuntu.com/security/CVE-2026-46065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46086", "url": "https://ubuntu.com/security/CVE-2026-46086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46003", "url": "https://ubuntu.com/security/CVE-2026-46003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46038", "url": "https://ubuntu.com/security/CVE-2026-46038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46026", "url": "https://ubuntu.com/security/CVE-2026-46026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46091", "url": "https://ubuntu.com/security/CVE-2026-46091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46078", "url": "https://ubuntu.com/security/CVE-2026-46078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46069", "url": "https://ubuntu.com/security/CVE-2026-46069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46021", "url": "https://ubuntu.com/security/CVE-2026-46021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46092", "url": "https://ubuntu.com/security/CVE-2026-46092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: check for PCI upstream bridge existence pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31700", "url": "https://ubuntu.com/security/CVE-2026-31700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31712", "url": "https://ubuntu.com/security/CVE-2026-31712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require minimum ACE size in smb_check_perm_dacl() Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31708", "url": "https://ubuntu.com/security/CVE-2026-31708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43350", "url": "https://ubuntu.com/security/CVE-2026-43350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: require a full NFS mode SID before reading mode bits parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31711", "url": "https://ubuntu.com/security/CVE-2026-31711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix active_num_conn leak on transport allocation failure Commit 77ffbcac4e56 (\"smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with \"Limit the maximum number of connections\". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31715", "url": "https://ubuntu.com/security/CVE-2026-31715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() The xfstests case \"generic/107\" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43492", "url": "https://ubuntu.com/security/CVE-2026-43492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting \"lzeros\" from the unsigned \"nbytes\". For this to happen, the scatterlist \"sgl\" needs to occupy more bytes than the \"nbytes\" parameter and the first \"nbytes + 1\" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than \"nbytes\", subtract the number of zeroes from \"nbytes\" and cause the underflow. When commit 2d4d1eea540b (\"lib/mpi: Add mpi sgl helpers\") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to \"nbytes\". However since commit 63ba4d67594a (\"KEYS: asymmetric: Use new crypto interface without scatterlists\"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger \"out_len\" than \"in_len\" and filling the \"in\" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the \"src\" and \"dst\" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "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.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-52933", "url": "https://ubuntu.com/security/CVE-2026-52933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix signed comparison in io_poll_get_ownership() io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2025-22026", "url": "https://ubuntu.com/security/CVE-2025-22026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2023-54125", "url": "https://ubuntu.com/security/CVE-2023-54125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Return error for inconsistent extended attributes ntfs_read_ea is called when we want to read extended attributes. There are some sanity checks for the validity of the EAs. However, it fails to return a proper error code for the inconsistent attributes, which might lead to unpredicted memory accesses after return. [ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0 [ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199 [ 138.931132] [ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4 [ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 138.947327] Call Trace: [ 138.949557] [ 138.951539] dump_stack_lvl+0x4d/0x67 [ 138.956834] print_report+0x16f/0x4a6 [ 138.960798] ? ntfs_set_ea+0x453/0xbf0 [ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200 [ 138.969793] ? ntfs_set_ea+0x453/0xbf0 [ 138.973523] kasan_report+0xb8/0x140 [ 138.976740] ? ntfs_set_ea+0x453/0xbf0 [ 138.980578] __asan_store4+0x76/0xa0 [ 138.984669] ntfs_set_ea+0x453/0xbf0 [ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10 [ 138.993390] ? kernel_text_address+0xd3/0xe0 [ 138.998270] ? __kernel_text_address+0x16/0x50 [ 139.002121] ? unwind_get_return_address+0x3e/0x60 [ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 139.010177] ? arch_stack_walk+0xa2/0x100 [ 139.013657] ? filter_irq_stacks+0x27/0x80 [ 139.017018] ntfs_setxattr+0x405/0x440 [ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10 [ 139.026569] ? kvmalloc_node+0x2d/0x120 [ 139.030329] ? kasan_save_stack+0x41/0x60 [ 139.033883] ? kasan_save_stack+0x2a/0x60 [ 139.037338] ? kasan_set_track+0x29/0x40 [ 139.040163] ? kasan_save_alloc_info+0x1f/0x30 [ 139.043588] ? __kasan_kmalloc+0x8b/0xa0 [ 139.047255] ? __kmalloc_node+0x68/0x150 [ 139.051264] ? kvmalloc_node+0x2d/0x120 [ 139.055301] ? vmemdup_user+0x2b/0xa0 [ 139.058584] __vfs_setxattr+0x121/0x170 [ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10 [ 139.066282] __vfs_setxattr_noperm+0x97/0x300 [ 139.070061] __vfs_setxattr_locked+0x145/0x170 [ 139.073580] vfs_setxattr+0x137/0x2a0 [ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10 [ 139.080223] ? __kasan_check_write+0x18/0x20 [ 139.084234] do_setxattr+0xce/0x150 [ 139.087768] setxattr+0x126/0x140 [ 139.091250] ? __pfx_setxattr+0x10/0x10 [ 139.094948] ? __virt_addr_valid+0xcb/0x140 [ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330 [ 139.102688] ? debug_smp_processor_id+0x1b/0x30 [ 139.105985] ? kasan_quarantine_put+0x5b/0x190 [ 139.109980] ? putname+0x84/0xa0 [ 139.113886] ? __kasan_slab_free+0x11e/0x1b0 [ 139.117961] ? putname+0x84/0xa0 [ 139.121316] ? preempt_count_sub+0x1c/0xd0 [ 139.124427] ? __mnt_want_write+0xae/0x100 [ 139.127836] ? mnt_want_write+0x8f/0x150 [ 139.130954] path_setxattr+0x164/0x180 [ 139.133998] ? __pfx_path_setxattr+0x10/0x10 [ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10 [ 139.141299] ? debug_smp_processor_id+0x1b/0x30 [ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80 [ 139.150796] __x64_sys_setxattr+0x71/0x90 [ 139.155407] do_syscall_64+0x3f/0x90 [ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 139.163843] RIP: 0033:0x7f108cae4469 [ 139.166481] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc [ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469 [ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6 [ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618 [ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0 [ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15 ---truncated---", "cve_priority": "high", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2026-31449", "url": "https://ubuntu.com/security/CVE-2026-31449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: validate p_idx bounds in ext4_ext_correct_indexes ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level. If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read. Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "high", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43064", "url": "https://ubuntu.com/security/CVE-2026-43064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix not releasing workqueue on .release() The workqueue associated with an DSA/IAA device is not released when the object is freed.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2165588, 2166457, 1786013, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2163508, 2164699, 1961566, 1956562, 2164516, 2137199, 2165170, 2165170, 2165166, 2165125, 2165125, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2164800 ], "changes": [ { "cves": [ { "cve": "CVE-2026-64582", "url": "https://ubuntu.com/security/CVE-2026-64582", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix a use-after-free problem in rxe_mmap rxe_mmap() removes a rxe_mmap_info struct from the pending_mmaps list and releases pending_lock while the struct's kref is still at 1: list_del_init(&ip->pending_mmaps); spin_unlock_bh(&rxe->pending_lock); /* ref == 1, no lock held */ ret = remap_vmalloc_range(vma, ip->obj, 0); /* walks PTEs */ [...] rxe_vma_open(vma); /* kref_get, ref → 2 */ remap_vmalloc_range_partial() walks PTEs without any lock. A concurrent DESTROY_CQ ioctl on another CPU calls: kref_put(&q->ip->ref, rxe_mmap_release) /* ref 1→0 */ vfree(ip->obj) /* clears vmalloc PTEs mid-walk */ kfree(ip) /* frees rxe_mmap_info */ This yields: 1. Kernel crash, vmalloc_to_page() returns NULL when vfree wins the per-PTE race -> vm_insert_page(NULL) → GPF in validate_page_before_insert 2. Page UAF, vmalloc_to_page() reads a stale PTE before vfree clears it. User VMA holds a PTE to a free'd page which might eventually get reallocated later by vmalloc which allows the attacker to get a clean page-level UAF. It is worth noting that even though a page-level UAF is possible given the strong primitive, it is statistically very difficult to achieve given the very short time window (after the last insert_page and before the kref_get). The call trace are as below: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 UID: 1000 PID: 413 Comm: poc Not tainted 7.0.0-rc5-dirty #28 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:validate_page_before_insert+0x32/0x300 Code: e5 41 57 41 56 49 89 fe 41 55 41 54 53 48 89 f3 e8 93 b5 a3 ff 48 8d 7b 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 7b 02 00 00 4c 8b 63 08 31 ff 4d 89 e5 41 83 e5 RSP: 0018:ffff88811b15f2f0 EFLAGS: 00000202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000008 RBP: ffff88811b15f318 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881181eee00 R13: 0000000000000000 R14: ffff8881181eee00 R15: ffff8881181eee20 FS: 00007b1e000f76c0(0000) GS:ffff8884268e0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007b1e00a24ac0 CR3: 0000000116eb3000 CR4: 00000000000006f0 Call Trace: insert_page+0x8f/0x190 ? __pfx_insert_page+0x10/0x10 ? kasan_save_alloc_info+0x38/0x60 vm_insert_page+0x2e7/0x400 remap_vmalloc_range_partial+0x212/0x3e0 remap_vmalloc_range+0x6e/0xb0 ? __kasan_check_write+0x14/0x30 rxe_mmap+0x2e9/0x5d0 ib_uverbs_mmap+0x1ad/0x2c0 __mmap_region+0x12c2/0x2ad0 ? __pfx___mmap_region+0x10/0x10 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_prev_slot+0x360/0x39c0 ? __sanitizer_cov_trace_switch+0x58/0xb0 ? mas_next_slot+0x1e5b/0x2f40 ? __sanitizer_cov_trace_cmp8+0x18/0x30 ? unmapped_area_topdown+0x4dd/0x610 ? kfree+0x1b1/0x440 ? free_cpumask_var+0x16/0x30 ? __kasan_slab_free+0x7d/0xa0 ? __sanitizer_cov_trace_cmp8+0x18/0x30 mmap_region+0x2e6/0x3c0 do_mmap+0xa3e/0x12a0 ? __pfx_do_mmap+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? down_write_killable+0xba/0x160 ? __pfx_down_write_killable+0x10/0x10 ? __sanitizer_cov_trace_cmp4+0x16/0x30 vm_mmap_pgoff+0x2d4/0x4a0 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x1bf/0x270 ksys_mmap_pgoff+0x40c/0x690 ? __sanitizer_cov_trace_const_cmp4+0x16/0x30 ? __pfx_ksys_mmap_pgoff+0x10/0x10 ? __kasan_check_write+0x14/0x30 ? _raw_spin_trylock+0xbb/0x130 ? __pfx__raw_spin_trylock+0x10/0x10 __x64_sys_mmap+0x135/0x1e0 x64_sys_c ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-05 12:18:00 UTC" }, { "cve": "CVE-2026-74468", "url": "https://ubuntu.com/security/CVE-2026-74468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: pch: use raw_spinlock_t for the register lock pch_irq_type() is registered as the irq_chip .irq_set_type callback and takes chip->spinlock with spin_lock_irqsave(). This callback is reached from __setup_irq() -> __irq_set_trigger() -> chip->irq_set_type() while the caller holds desc->lock, a raw_spinlock_t, with hardirqs disabled. That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is an rtmutex-backed sleeping lock, so acquiring it there is invalid. This was confirmed on a PREEMPT_RT kernel with lockdep (PROVE_RAW_LOCK_NESTING and DEBUG_ATOMIC_SLEEP). A grounded PoC mirrored pch_irq_type()'s locking and drove it through the real genirq carrier irq_set_irq_type() -> __irq_set_trigger() -> chip->irq_set_type(), i.e. the same __irq_set_trigger() edge that __setup_irq() takes for a requested IRQ. With the original spin_lock_irqsave() edge lockdep reported an invalid wait context, immediately followed by: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 95, name: insmod hardirqs last disabled at (3784): _raw_spin_lock_irqsave+0x4f/0x60 rt_spin_lock+0x3a/0x1c0 repro_irq_set_type+0x64/0xa0 [pch_repro] __irq_set_trigger+0x69/0x140 irq_set_irq_type+0x78/0xd0 Switching the mirrored lock to raw_spinlock_t made both splats go away. Convert the register lock to raw_spinlock_t. The same lock also serializes the GPIO direction/value callbacks and the suspend/resume register save/restore, but all of those critical sections only perform MMIO register accesses (ioread32()/iowrite32()) and irq_set_handler_locked(); none of them contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract. This is the same class of issue and fix as recently addressed for other GPIO controllers, e.g. commit 286533cb14a3 (\"gpio: sch: use raw_spinlock_t in the irq startup path\") and commit 90f0109019e6 (\"gpio: eic-sprd: use raw_spinlock_t in the irq startup path\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74482", "url": "https://ubuntu.com/security/CVE-2026-74482", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74443", "url": "https://ubuntu.com/security/CVE-2026-74443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: bound DMA command body size against suffix pointer vmw_cmd_dma() locates the DMA suffix at \t(unsigned long) &cmd->body + header->size - sizeof(*suffix) without checking that header->size is large enough to contain both cmd->body and the suffix. An undersized header makes the suffix pointer underflow back into the previous command in the bounce buffer. The verifier later writes suffix->maximumOffset, clobbering verified fields of an already-relocated earlier command -- a TOCTOU on the device-visible command stream that lets one command rewrite another's GMR id, surface id, or other authenticated fields. Reject the command if the body is too small for the suffix to fit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74444", "url": "https://ubuntu.com/security/CVE-2026-74444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: validate DRAW_PRIMITIVES header size before division vmw_cmd_draw() computes \tmaxnum = (header->size - sizeof(cmd->body)) / sizeof(*decl); where header->size is u32 and is taken straight from the user-supplied command stream. When header->size is less than sizeof(cmd->body) the unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum. Any user-controlled cmd->body.numVertexDecls then passes the bound and the loop dereferences decl[i] far past the end of the kernel command bounce buffer, producing an out-of-bounds read of kernel memory. Reject undersized headers up front.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74453", "url": "https://ubuntu.com/security/CVE-2026-74453", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Zero the tile state data array before each BIN job The binner BO is a single 16MB buffer split into 512KB slots that are handed out to jobs at submission time and recycled as jobs complete, without ever being cleared. Each slot holds the job's Tile State Data Array (TSDA) at its start, followed by the tile allocation pool. While the tile allocation pool is only walked by the render thread through branches the binner generated during the current job, the TSDA is the PTB's own per-tile bookkeeping and is consumed by the hardware itself. Although the kernel sets the \"Auto-initialise Tile State Data Array\" flag in the tile binning mode configuration, the PTB demonstrably still acts on stale tile state left by the slot's previous user: the binner ends up creating invalid command streams with invalid primitive streams and branches, which can cause GPU hangs as observed in [1][2]. Zero the TSDA when the job's binning slot is configured. This clears 48 bytes per tile (~24KB for a 1080p frame) in the submission path, and guarantees the PTB never sees another job's tile state. The tile count is only checked for being non-zero today, so the 8-bit fields it comes from can describe a tile state array almost six times larger than the slot it has to live in. Bound it before the slot is handed out, since such size decides how much of the slot is left for the tile alloc pool.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74455", "url": "https://ubuntu.com/security/CVE-2026-74455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: validate uCAN receive record lengths pcan_usb_fd_decode_buf() walks uCAN records packed in one USB receive buffer. Require each record to contain the fixed header for its type, and verify CAN payload bytes before copying them into the skb.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74456", "url": "https://ubuntu.com/security/CVE-2026-74456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc() and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also frees the transfer buffer. If usb_submit_urb() fails, the error path frees the buffer explicitly with kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set, usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double free of the transfer buffer. BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0 Free of addr ffff8881069ccb80 by task trigger.sh/285 Call Trace: kfree+0x113/0x3c0 usb_free_urb.part.0+0x91/0xb0 Drop the redundant kfree(buf); usb_free_urb() already releases the transfer buffer. This mirrors commit 03819abbeb11 (\"net: usb: lan78xx: Fix double free issue with interrupt buffer allocation\").", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74457", "url": "https://ubuntu.com/security/CVE-2026-74457", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: peak_usb: add bounds check for USB channel index The channel control index ctrl_idx is derived from rx->len which comes directly from a device USB payload. The mask 0x0f allows values 0-15, but the array size of usb_if->dev[] is only 2. Values 2-15 cause heap out-of-bounds read, eventually causing kernel panic in the IRQ context. Add bounds checking for ctrl_idx before the array access in both pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74458", "url": "https://ubuntu.com/security/CVE-2026-74458", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents The wait and bulk receive paths walk variable-length commands from a USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be dispatched, and the wait path copies a matching command into a fixed caller-owned struct kvaser_cmd using the device-provided length. Reject nonzero commands that do not contain the fixed header or that extend beyond the current USB buffer item. In the wait path, also reject a matching command that exceeds the destination before copying it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74459", "url": "https://ubuntu.com/security/CVE-2026-74459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure es58x_read_bulk_callback() resubmits the RX URB after processing a received packet. If the resubmit succeeds, the URB remains anchored and will be handled by the normal RX path or by teardown. However, if usb_submit_urb() fails, the callback unanchors the URB and then returns directly. This skips the existing free_urb path, so the coherent transfer buffer allocated with usb_alloc_coherent() is not released. Reuse the existing free_urb path after a resubmit failure so that the RX coherent buffer is freed before leaving the callback.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74460", "url": "https://ubuntu.com/security/CVE-2026-74460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ems_usb: validate CPC message lengths ems_usb_read_bulk_callback() walks CPC messages packed in one USB receive buffer. Check that each declared message fits in the URB payload. Also require the type-specific payload to cover the fields used by the CAN, state, error and overrun handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74461", "url": "https://ubuntu.com/security/CVE-2026-74461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: Cancel hrtimer before clearing slave pointer In i2c_imx_unreg_slave(), the slave pointer is set to NULL after disabling interrupts. However, a pending interrupt might already have started the hrtimer (i2c_imx_slave_timeout) before the pointer was cleared. If the hrtimer fires after i2c_imx->slave is set to NULL, the timer callback i2c_imx_slave_finish_op() will call i2c_imx_slave_event() with a NULL slave pointer, which results in a use-after-free / NULL pointer dereference. Fix by canceling the hrtimer and waiting for it to complete after disabling interrupts, before clearing the slave pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74463", "url": "https://ubuntu.com/security/CVE-2026-74463", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock deadlock Fix a severe AB/BA deadlock between the Common Clock Framework (CCF) and the I2C adapter lock, which triggers when an I2C-controlled clock generator client (like the Si5351) is registered or modified under the CCF. During an i2c client clock (generator) frequency change, the CCF acquires its global 'prepare_lock' mutex and the driver calls i2c_transfer() to update the client's chip registers, stalling for the adapter's I2C bus lock. Concurrently, an independent, parallel transfer on the same bus (e.g., a GPIO expander handling LEDs) can hold the I2C adapter lock. Inside this parallel transfer path, jz4780_i2c_set_speed() calls clk_get_rate() on the host controller's input clock to calculate bus timings. This call attempts to acquire the blocked CCF 'prepare_lock', creating a circular dependency that freezes the system. The jz4780 host controller clock itself is static and never changes at runtime. However, calling clk_get_rate() inside the active transfer path introduces an unnecessary dependency on the CCF internal locks. Eliminate this synchronous clk_get_rate() call from the active transfer path by caching the static host peripheral clock rate once - inside the private jz4780_i2c structure during jz4780_i2c_probe(). Update jz4780_i2c_set_speed() to use this cached value, safely decoupling active I2C transactions from the CCF internal locks without any risk of stale timings. Assisted-by web based Google AI (pinpointing the bug and writing the message).", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74464", "url": "https://ubuntu.com/security/CVE-2026-74464", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix skb leak on flow key update failure during ct ovs_ct_execute() always steals or frees the skb on failure while ovs_flow_key_update() does not. So, if it fails and we return right away, the skb ends up leaked. Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly. This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless. Reported by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74465", "url": "https://ubuntu.com/security/CVE-2026-74465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix potential UAF on meter attach failure While attaching a newly created meter attach_meter() function makes the new meter visible to other CPUs but can still fail afterwards. On failure, it detaches the meter back and returns an error. However, this is an unexpected behavior for the ovs_meter_cmd_set() that uses a plain kfree(meter) on attach failure without waiting for RCU readers to stop using it, assuming it was never visible. This is never a problem for ovs-vswitchd as it always creates meters before creating any flows that use them. But the UAF can be triggered with a custom application using uAPI: BUG: KASAN: slab-use-after-free in ovs_meter_execute (net/openvswitch/meter.c:653) Read of size 8 at addr ffff88810d152650 by task meter/2508 Call Trace: ovs_meter_execute (net/openvswitch/meter.c:653) do_execute_actions (net/openvswitch/actions.c:1407) ovs_execute_actions (net/openvswitch/actions.c:1584) ovs_packet_cmd_execute (net/openvswitch/datapath.c:703) ... netlink_sendmsg (af_netlink.c:1900) Allocated by task 2519: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) ovs_meter_cmd_set (net/openvswitch/meter.c:422) ... netlink_sendmsg (af_netlink.c:1900) Freed by task 2519: kfree (mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720) ovs_meter_cmd_set (net/openvswitch/meter.c:479) ... netlink_sendmsg (af_netlink.c:1900) Fix that by making sure attach_meter() doesn't make the meter visible until all the checks are done and the function can't fail anymore. This also makes sure the \"hash\" value is calculated after the potential re-sizing of the table. Reported by Trend Micro's Zero Day Initiative as ZDI-CAN-31642.", "cve_priority": "high", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-68451", "url": "https://ubuntu.com/security/CVE-2026-68451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA ECC private key requests cca_ecc2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "high", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-68452", "url": "https://ubuntu.com/security/CVE-2026-68452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: Validate length for CCA AES cipher key requests cca_cipher2protkey() derives the copy length for the CPRB parameter block directly from the length field in the key token. Reject the request early if the token length exceeds the available space in the parameter block.", "cve_priority": "medium", "cve_public_date": "2026-08-13 15:19:00 UTC" }, { "cve": "CVE-2026-74467", "url": "https://ubuntu.com/security/CVE-2026-74467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/qeth: Check CAP_NET_ADMIN for private ioctls Gate the SIOCDEVPRIVATE ioctl commands SIOC_QETH_ADP_SET_SNMP_CONTROL, SIOC_QETH_GET_CARD_TYPE and SIOC_QETH_QUERY_OAT with CAP_NET_ADMIN capable check to ensure unprivileged users cannot invoke them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74469", "url": "https://ubuntu.com/security/CVE-2026-74469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: prevent peer transport count overflow sctp_assoc_add_peer() increments the association's 16-bit transport_count for every new unique peer. Adding the 65,536th transport wraps the count to zero. SCTP sock_diag uses transport_count to reserve the INET_DIAG_PEERS payload, then copies one sockaddr_storage for every entry in transport_addr_list. After the wrap, a diagnostic dump reserves an empty payload and writes 8 MiB of peer addresses past the skb tail. Reject a new unique peer when transport_count has reached U16_MAX. Perform the check after the existing-peer lookup so a duplicate address continues to return its existing transport at the limit.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74471", "url": "https://ubuntu.com/security/CVE-2026-74471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Check return value of __register_event() in trace_module_add_events() trace_module_add_events() ignores the return value of __register_event() and unconditionally calls __add_event_to_tracers() for each event. If __register_event() fails (for example, if event_init() fails), the trace_event_call is not added to ftrace_events list, but __add_event_to_tracers() still creates a trace_event_file pointing to it. If module loading subsequently fails and module memory is freed, tracing state retains a stale trace_event_call pointer in trace_event_file, leading to a use-after-free when tracefs or tracing subsystem operations are later executed. Fix this by checking the return value of __register_event() and only calling __add_event_to_tracers() if event registration succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74473", "url": "https://ubuntu.com/security/CVE-2026-74473", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use pskb_network_may_pull() in route_shortcircuit() route_shortcircuit() currently calls pskb_may_pull(skb, sizeof(struct iphdr)) (or ipv6hdr), which checks if bytes are available starting from skb->data. However, in vxlan_xmit(), skb->data points to the MAC header, so skb_network_offset(skb) is ETH_HLEN (14 bytes). Using pskb_may_pull(skb, 20) only checks 20 bytes from skb->data (which is 14 bytes MAC header + 6 bytes of IP header), leaving the rest of the IP header potentially un-pulled in non-linear frags. Subsequent dereferences of ip_hdr(skb)->daddr can read beyond the pulled linear buffer length. Fix this by using pskb_network_may_pull(), which adds skb_network_offset(skb) to the length check to ensure the full network header is present in the linear buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74475", "url": "https://ubuntu.com/security/CVE-2026-74475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: use neigh_ha_snapshot() in route_shortcircuit() The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->ha_lock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address. Use neigh_ha_snapshot() in route_shortcircuit() to safely copy n->ha under read_seqbegin()/read_seqretry() lock protection before using it. Note that arp_reduce() and neigh_reduce() seem to have the same issue left for future patches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74478", "url": "https://ubuntu.com/security/CVE-2026-74478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: um: vector: fix use-after-free in vector_mmsg_rx() When vector_mmsg_rx() discards a packet whose overlay header fails verify_header(), it frees the skb and continues the loop: \tif (header_check < 0) { \t\tdev_kfree_skb_irq(skb); \t\tvp->estats.rx_encaps_errors++; \t\tcontinue; \t} The normal and short-packet paths fall through to the bottom of the loop body, which clears the consumed slot and advances the cursors: \t(*skbuff_vector) = NULL; \tmmsg_vector++; \tskbuff_vector++; The verify_header() < 0 path skips that via continue, so the freed skb is left in skbuff_vector[] and the cursors do not advance. The next iteration reads the same slot, gets the freed skb, and frees it again, producing a refcount underflow / use-after-free in the RX path. Discard the slot the same way the other paths do before continuing. Only transports whose verify_header() can return negative are affected: GRE and L2TPv3 do so on a cookie/session-id mismatch (raw/tap do not), so any peer on such a transport can trigger it without authentication.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74480", "url": "https://ubuntu.com/security/CVE-2026-74480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches those entries by port only. A fast leave can then delete one entry and continue from its stale next pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74481", "url": "https://ubuntu.com/security/CVE-2026-74481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/page_reporting: use system_freezable_wq to fix UAF during suspend During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74485", "url": "https://ubuntu.com/security/CVE-2026-74485", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: reject a flag character as the field delimiter The registration string starts with a user chosen delimiter that separates the individual fields. So that the field parsers terminate even on a truncated string create_entry() pads the buffer with that same delimiter: \tmemset(buf + count, del, 8); Most fields are scanned for the delimiter with strchr()/scanarg() and happily stop on the padding. The flags field is different: instead of scanning for the delimiter check_special_flags() consumes the flag characters 'P', 'O', 'C' and 'F' and stops at the first byte that is none of them, relying on the trailing delimiter to end the scan. If the delimiter is itself a flag character the padding no longer acts as a terminator. The scan swallows all eight padding bytes and keeps reading past the end of the allocation until it hits a byte that is not a flag character. For example registering \tPaPEPPxPPiP with 'P' as the delimiter (name \"a\", type extension, magic \"x\", interpreter \"i\", empty flags) leaves the flag scan running off the end of the buffer. The registration is rejected in the end because the parser does not stop exactly at buf + count, but only after the out of bounds read has already happened. With an unlucky allocation layout the scan can walk into an unmapped page; under KASAN it is reported as a slab out of bounds read. binfmt_misc mounts are available to unprivileged users in a user namespace so the read is reachable without privileges. Reject a delimiter that is one of the flag characters up front. Such a registration was always rejected anyway, only after the out of bounds read, so no valid registration string changes meaning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74488", "url": "https://ubuntu.com/security/CVE-2026-74488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames mwifiex_11n_dispatch_amsdu_pkt() splits an A-MSDU with ieee80211_amsdu_to_8023s() and walks the resulting subframes. For each subframe it passes the subframe data pointer to mwifiex_process_tdls_action_frame(), but pairs it with skb->len, the length of the A-MSDU parent, instead of rx_skb->len: \trx_skb = __skb_dequeue(&list); \trx_hdr = (struct rx_packet_hdr *)rx_skb->data; \tif (ISSUPP_TDLS_ENABLED(priv->adapter->fw_cap_info) && \t ntohs(rx_hdr->eth803_hdr.h_proto) == ETH_P_TDLS) { \t\tmwifiex_process_tdls_action_frame(priv, (u8 *)rx_hdr, \t\t\t\t\t\t skb->len); \t} The parent is not a valid description of that buffer, and may not be valid memory at all. ieee80211_amsdu_to_8023s() ends with \tif (!reuse_skb) \t\tdev_kfree_skb(skb); and it only sets reuse_skb when the parent is linear, is not a head_frag, and is being consumed as the *last* subframe. So when the parent does not qualify for reuse it has already been freed, and the read of skb->len is a use-after-free. When it is reused, skb->len is the length of the last subframe, applied to every earlier subframe, which over-states the buffer whenever an earlier subframe is shorter. The callee cannot absorb a wrong length, because it derives its own ceiling from the value it is given. Each frame type computes \ties_len = len - sizeof(struct ethhdr) - TDLS_*_FIX_LEN; and the element walk is then bounded entirely against that ceiling, \tfor (end = pos + ies_len; pos + 1 < end; pos += 2 + pos[1]) { \t\tu8 ie_len = pos[1]; \t\tif (pos + 2 + ie_len > end) \t\t\tbreak; so a too-large len moves end past the end of the subframe and the walk reads and copies beyond it. The A-MSDU layout is chosen by the sender, which makes the difference between the last subframe and a shorter earlier one remotely selectable. Reaching this requires TDLS support in firmware and the TDLS ethertype on the subframe. The other caller, mwifiex_process_rx_packet(), is correct: it passes a pointer and a length that describe the same region of the RX buffer. Pass rx_skb->len, the length of the subframe actually being parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74490", "url": "https://ubuntu.com/security/CVE-2026-74490", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: avoid use-after-free in poll trace queue dumps TIPC socket tracepoints dump queue state through tipc_sk_dump(). Most queue-dump callsites already serialize that walk under the socket lock or sk->sk_lock.slock, but tipc_poll() calls trace_tipc_sk_poll(..., TIPC_DUMP_ALL, ...) without holding either lock. That lets the poll trace path reach tipc_list_dump() and backlog head/tail dumping while another context dequeues and frees an skb, leaving the trace helper dereferencing a stale queue entry. Stop the unlocked poll trace site from requesting queue dumps. Other queue dump trace callsites keep their existing output under the locking they already provide, while poll still emits the event itself without walking live queue members from an unlocked context.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74492", "url": "https://ubuntu.com/security/CVE-2026-74492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: do not update comments from kernel-side hash adds mtype_resize() copies comment pointers with memcpy(), not the comment objects themselves. During the window after an entry has been copied but before the table swap and backlog replay, the old table is still published for packet-side updates while the replacement-table entry already holds the same ip_set_comment_rcu pointer. If xt_SET --add-set ... --exist hits that old entry in this window, mtype_add() calls ip_set_init_comment() even though packet-side adds carry no comment payload. That call frees the shared comment through the old entry, so the replacement-table entry now holds a stale pointer. When the queued add is replayed on the new table, mtype_add() calls ip_set_init_comment() again and strlen() dereferences the stale pointer. Fix this in mtype_add() by skipping ip_set_init_comment() when ext->target marks a packet-side add. Userspace adds still update comments, while packet-side adds can no longer free comment storage shared with a resize copy.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74493", "url": "https://ubuntu.com/security/CVE-2026-74493", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket use-after-free during link group termination __smc_lgr_terminate() drops conns_lock after finding a connection in lgr->conns_all, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree. A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sock_hold(). The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported: BUG: KASAN: slab-use-after-free in __smc_lgr_terminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smc_lgr_terminate_work [smc] __smc_lgr_terminate.part.0 [smc] The socket was allocated by smc_create(), freed through slab_free_after_rcu_debug(), and was followed by: refcount_t: addition on 0; use-after-free. __smc_lgr_terminate.part.0 [smc] Take the socket reference while conns_lock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74495", "url": "https://ubuntu.com/security/CVE-2026-74495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igbvf: Fix leak in TX DMA error cleanup If an error is encountered while mapping TX buffers, the driver should unmap any buffers already mapped for that skb. Because count is incremented before each frag mapping, it will always match the correct number of unmappings needed when dma_error is reached. Decrementing count before the while loop in dma_error causes an off-by-one error. If any mapping was successful before an unsuccessful mapping, exactly one DMA mapping (the head) would leak. This bug was introduced by a 2010 fix for an endless loop in dma_error. All other affected drivers have already been fixed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74497", "url": "https://ubuntu.com/security/CVE-2026-74497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Clamp frame size in implicit-feedback mode snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's stride and stores the result directly in out_packet->packet_size[i]. If a connected USB device sends an oversized sync packet, this frame count can exceed ep->maxframesize. The un-clamped frame count then propagates to the playback endpoint queue, potentially driving packet transfers beyond the endpoint's hardware frame limits. Cap the calculated frame count against ep->maxframesize in snd_usb_handle_sync_urb() to prevent oversized packets from entering the playback queue.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74498", "url": "https://ubuntu.com/security/CVE-2026-74498", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set When a USB audio endpoint requests full packet transfers via the fill_max descriptor flag, data_ep_set_params() promotes ep->curpacksize to ep->maxpacksize. However, maxsize is left at the original sample-rate derived value. Since u->buffer_size is allocated as maxsize * packets, the resulting DMA buffer is far too small for the requested transfer length. When the USB host controller streams up to curpacksize bytes per packet, it writes past the end of the buffer via DMA, corrupting kernel heap memory. Update maxsize to curpacksize when fill_max is set so that the allocated DMA buffer size matches the actual transfer request size. [ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74499", "url": "https://ubuntu.com/security/CVE-2026-74499", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output() snd_usbmidi_akai_output() computes its fill-loop bound \tbuf_end = ep->max_transfer - MAX_AKAI_SYSEX_LEN - 1; as a signed int, so a small device-advertised bulk-OUT max_transfer makes buf_end negative. The loop guard then compares the u32 urb->transfer_buffer_length against that negative int: the usual arithmetic conversion turns buf_end into a large unsigned value, so the guard stays true and each iteration keeps appending SysEx framing and payload bytes past the end of the URB transfer buffer, which is only max_transfer bytes long. A USB device that advertises a tiny bulk-OUT endpoint can therefore trigger an attacker-length- and content-controlled heap out-of-bounds write when a process writes to the created /dev/snd/midiC*D* node. Return early when there is no room for even one SysEx, so the loop is never entered with a bound that would wrap. The loop is the last statement of the function, so bailing out is equivalent to it not running. Discovered by XBOW, triaged by Baul Lee ", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74505", "url": "https://ubuntu.com/security/CVE-2026-74505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Fix UAF at error handling during probe Although 6fire driver had a few fixes for dealing with the early error handling during the probe phase, it forgot a pending URB before freeing the resources, which may lead to a UAF. This patch addresses it by doing the almost same cleanup procedure like the normal disconnect phase at the error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74507", "url": "https://ubuntu.com/security/CVE-2026-74507", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: validate numbered report payloads When hidp_get_raw_report() waits for a numbered report, hidp_process_data() compares the expected report number with skb->data[0]. A connected HIDP peer can reply with only a DATA transaction header, leaving the skb empty after the header is removed. KMSAN reports an uninitialized-value use in hidp_session_run(), with the value originating in __alloc_skb() through vhci_write(). The transaction header checks remove the empty-frame reports, but this report remains until the payload check is added. The comparison can also consume a peer-controlled byte beyond the declared L2CAP PDU. A DATA | FEATURE response followed by an extra 0x01 byte made the current code accept that byte as report ID 1 and complete HIDIOCGFEATURE with a zero-byte result. With this change the malformed response is rejected with -EIO, while a subsequent valid response still succeeds. Require a payload byte before comparing a numbered report ID. Unnumbered reports continue to accept an empty payload.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74508", "url": "https://ubuntu.com/security/CVE-2026-74508", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HIDP: reject frames without a transaction header hidp_recv_ctrl_frame() and hidp_recv_intr_frame() read skb->data[0] before checking that the L2CAP SDU contains a transaction header. A connected HIDP peer can send an empty basic-mode SDU and make both paths use an uninitialized byte from skb tailroom. KMSAN reports the use in hidp_session_run(), with the uninitialized value originating in __alloc_skb() through vhci_write(). The control path produces two reports and the interrupt path produces one. The byte can also be controlled by a malformed lower-layer packet. If an HCI ACL packet contains an L2CAP PDU with a declared zero-length payload followed by an extra 0x15 byte, l2cap_recv_acldata() reduces skb->len to the declared PDU length before dispatch. The current HIDP path nevertheless consumes the extra byte as HIDP_TRANS_HID_CONTROL | HIDP_CTRL_VIRTUAL_CABLE_UNPLUG and terminates the HIDP session. With this change, the same packet is discarded and a subsequent feature report request succeeds. Pull the transaction header with skb_pull_data() and discard frames that do not contain it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74512", "url": "https://ubuntu.com/security/CVE-2026-74512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix potential use-after-free in audit_del_rule() `audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()` before unlinking the rule from RCU-visible filter lists and waiting for a grace period. Concurrent readers in `audit_filter()` and `audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify mark can be freed on an independent lifetime path. This creates a use-after-free window during rule deletion. Fix this by unlinking the rule from the RCU-visible lists and invoking `synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other rule removal helpers). This ensures that all existing RCU readers have exited the critical section before any underlying resources are destroyed.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74518", "url": "https://ubuntu.com/security/CVE-2026-74518", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix list corruption in allocate_file_region_entries() allocate_file_region_entries() tops up resv->region_cache with freshly allocated file_region descriptors. The allocation uses GFP_KERNEL, so resv->lock is dropped around it: the new entries are gathered on a stack-local list head, allocated_regions, and spliced into resv->region_cache once the lock is re-acquired. The splice used list_splice(), which moves the entries but does not re-initialize the source head, so allocated_regions is left pointing at an entry that now lives on resv->region_cache. The top-up runs in a while loop that re-checks the cache deficit after re-acquiring the lock. For a shared mapping the resv_map is shared by every mapper of the hugetlbfs inode, so a concurrent region_chg()/region_add()/region_del() on the same resv_map can consume cache entries during the unlocked window and force a second iteration. That iteration calls list_add() on the stale head and corrupts the list; with CONFIG_DEBUG_LIST the __list_add_valid() check trips: list_add corruption. next->prev should be prev (ffffc900011ff7f8), but was ffff88814c281460. (next=ffff88814c545640). kernel BUG at lib/list_debug.c:31! allocate_file_region_entries+0x191/0x420 region_chg+0x267/0x300 hugetlb_reserve_pages+0x387/0xc80 hugetlbfs_file_mmap+0x2ce/0x3f0 mmap_region+0x1348/0x1a80 do_mmap+0x85e/0xb90 vm_mmap_pgoff+0x18c/0x330 ksys_mmap_pgoff+0x2a1/0x3e0 do_syscall_64+0xd7/0x420 Without CONFIG_DEBUG_LIST the bad list_add() silently links a kernel-stack address into resv->region_cache, leading to later use-after-free. This was observed as a real host panic on a dense KVM host where a QEMU guest-RAM hugetlbfs file was mapped MAP_SHARED by both QEMU and a separate SPDK/DPDK vhost-user target, generating concurrent region_* traffic on one shared resv_map. Use list_splice_init() so the source head is re-initialized empty after each splice, making the retry loop safe.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74519", "url": "https://ubuntu.com/security/CVE-2026-74519", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: devicetree: don't free uninitialized dev_name on error path dt_remember_or_free_map() duplicates dev_name for each map entry. If kstrdup_const() fails, dt_free_map() frees dev_name in all num_maps entries, including entries that have not been initialized. Some pinctrl drivers, including pinctrl-imx, allocate the map with kmalloc() and leave dev_name for the core to initialize. The untouched entries therefore contain uninitialized data which is passed to kfree_const(). Reproduced on qemu's mcimx6ul-evk (pinctrl-imx) with failslab injection while binding the pinctrl-consuming device, under KASAN: BUG: KASAN: double-free in dt_free_map+0x34/0xa4 Free of addr c425a900 by task init/1 kfree from dt_free_map+0x34/0xa4 dt_free_map from dt_remember_or_free_map+0x184/0x198 dt_remember_or_free_map from pinctrl_dt_to_map+0x33c/0x4c8 pinctrl_dt_to_map from create_pinctrl+0x9c/0x5c0 Initialize all dev_name fields to NULL before duplicating the device name, making the full-map cleanup safe after a partial failure.", "cve_priority": "low", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-64563", "url": "https://ubuntu.com/security/CVE-2026-64563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rhashtable: clear stale iter->p on table restart rhashtable_walk_start_check() has two restart paths when resuming a walk. When iter->walker.tbl is valid, it re-validates iter->p against the table and sets iter->p = NULL if the object is gone. When iter->walker.tbl is NULL (table was freed during resize), it resets slot and skip but forgets to clear iter->p. rhashtable_walk_next() then dereferences the stale iter->p, reading freed memory. This is a use-after-free. Any caller that does multi-fragment rhashtable walks across walk_stop/walk_start boundaries is affected. Concrete cases include netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC (tipc_nl_sk_walk in net/tipc/socket.c). Crash stack (netlink_diag): BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0 Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080) Call Trace: rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016) __netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122) netlink_diag_dump+0xc2/0x240 netlink_dump+0x5bc/0x1270 netlink_recvmsg+0x7a3/0x980 sock_recvmsg+0x1bc/0x200 __sys_recvfrom+0x1d4/0x2c0", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-74523", "url": "https://ubuntu.com/security/CVE-2026-74523", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: sync udp_tunnel ports outside qede_lock in the recovery path A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74525", "url": "https://ubuntu.com/security/CVE-2026-74525", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sxgbe: free TX rings on RX allocation failure When RX descriptor ring allocation fails, init_dma_desc_rings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked. Rearrange error labels to clean up TX rings upon RX failures.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74540", "url": "https://ubuntu.com/security/CVE-2026-74540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp l2cap_le_connect_rsp() obtains a channel via __l2cap_get_chan_by_ident() but neither holds a reference nor uses l2cap_chan_hold_unless_zero() before locking and operating on it. A concurrent l2cap_chan_del() triggered by a remote disconnect can free the channel between the lookup and l2cap_chan_lock(), causing a use-after-free. The BR/EDR counterpart l2cap_connect_rsp() and the sibling handler l2cap_le_command_rej() already use l2cap_chan_hold_unless_zero() to safely hold a reference, but l2cap_le_connect_rsp() was left unprotected. Fix by adding l2cap_chan_hold_unless_zero() after the ident lookup and l2cap_chan_put() on the exit path, consistent with other L2CAP response handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74546", "url": "https://ubuntu.com/security/CVE-2026-74546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read If the fan data becomes 0 between the FAN_DATA_VALID() check and the FAN_PERIOD_TO_RPM() conversion, it will result in a divide-by-zero crash due to a race with a concurrent update of the cached fan value. Fix a TOCTOU issue by reading fan data once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:17:00 UTC" }, { "cve": "CVE-2026-74547", "url": "https://ubuntu.com/security/CVE-2026-74547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74548", "url": "https://ubuntu.com/security/CVE-2026-74548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: forcedeth: fix UAF of txrx_stats in nv_remove nv_remove() frees the per-CPU txrx_stats before unregister_netdev(). Until unregister completes, ndo_get_stats64, the NAPI/xmit data path, and nv_close()/drain may still access txrx_stats, leading to a use-after-free. Free the stats only after unregister_netdev().", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74549", "url": "https://ubuntu.com/security/CVE-2026-74549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) Prevent access to unsupported weight registers Sashiko reports: During initialization of the nct6116 chip, the driver sets data->pwm_num to 5. However, it assigns several NCT6106 register arrays (such as NCT6106_REG_WEIGHT_DUTY_STEP, NCT6106_REG_WEIGHT_TEMP_SEL, and NCT6106_REG_WEIGHT_TEMP_*) to data->REG_PWM and data->REG_WEIGHT_TEMP. These arrays only contain 3 elements. In nct6775_update_pwm(), the driver iterates up to data->pwm_num. If data->has_pwm has bits 3 or 4 set (which is structurally possible for nct6116), the loop attempts to read elements at index 3 and 4 from these 3-element arrays. This results in a global out-of-bounds read, which can be caught by KASAN. Furthermore, the driver uses these garbage out-of-bounds values as hardware register addresses for subsequent read and write operations. This leads to invalid hardware register access, potentially causing hardware misconfiguration or system crashes. The underlying problem is that the chip does support up to five fan control channels, but only the first three support weight control. Fix the problem by extending the affected weight register arrays with zeroed fields. The driver uses zeroed register addresses to determine if a register is supported or not, and skips accesses for unsupported registers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74556", "url": "https://ubuntu.com/security/CVE-2026-74556", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection buffer iscsi_tcp_hdr_dissect() receives the data segment of several PDU types into the fixed-size conn->data buffer, which is allocated for ISCSI_DEF_MAX_RECV_SEG_LEN (8192) bytes. For the LOGIN_RSP, TEXT_RSP, REJECT and ASYNC_EVENT opcodes the dissect path already rejects a PDU whose DataSegmentLength exceeds that buffer. The SCSI Command Response (ISCSI_OP_SCSI_CMD_RSP) path also copies its data segment (sense/response data) into conn->data via iscsi_tcp_data_recv_prep(), but it does so without the same check. The only upstream bound on in.datalen is conn->max_recv_dlength, the initiator's advertised MaxRecvDataSegmentLength, which is commonly negotiated well above 8192 (open-iscsi defaults to 262144). A target that returns a SCSI Response with a DataSegmentLength between 8193 and max_recv_dlength therefore overflows the 8192-byte conn->data buffer. Once the same bound applies, ISCSI_OP_SCSI_CMD_RSP is handled exactly like those responses: bound the data segment, receive it into conn->data when present, and otherwise complete the PDU with no data. Fold the opcode into that case group rather than duplicating the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74557", "url": "https://ubuntu.com/security/CVE-2026-74557", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer iscsi_scsi_cmd_rsp() copies the sense data of a SCSI Response from the target-supplied data segment. The segment carries a 2-byte sense length followed by the sense bytes, so it must hold 2 + senselen bytes, but the bounds check only requires datalen >= senselen: \tsenselen = get_unaligned_be16(data); \tif (datalen < senselen) \t\tgoto invalid_datalen; \tmemcpy(sc->sense_buffer, data + 2, \t min_t(uint16_t, senselen, SCSI_SENSE_BUFFERSIZE)); A target that returns a SCSI Response whose datalen equals senselen (with senselen <= SCSI_SENSE_BUFFERSIZE) makes the memcpy() from data + 2 read up to two bytes past the received data. Those bytes are stale conn->data contents and end up in the command's sense buffer, which is returned to userspace. Account for the 2-byte sense length prefix in the check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74563", "url": "https://ubuntu.com/security/CVE-2026-74563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: hold the RCU lock across ipv6_chk_addr() in rds_tcp_laddr_check() rds_tcp_laddr_check() looks up a scoped IPv6 interface with dev_get_by_index_rcu(), drops the RCU read-side lock, and only then passes the bare struct net_device * into ipv6_chk_addr(). dev_get_by_index_rcu() only keeps the device alive within the same RCU read-side section. After rcu_read_unlock(), a concurrent RTM_DELLINK can free the net_device; ipv6_chk_addr() then dereferences the stale pointer in __ipv6_chk_addr_and_flags() (e.g. l3mdev_master_dev_rcu(dev)), reading freed memory. Keep the RCU read-side lock held across the ipv6_chk_addr() call instead of dropping it right after the lookup, so the device cannot be freed while it is in use. BUG: KASAN: slab-use-after-free in __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) Read of size 8 at addr ffff8880106ec000 by task exploit/153 Call Trace: ... kasan_report (mm/kasan/report.c:595) __ipv6_chk_addr_and_flags (... net/ipv6/addrconf.c:1998) ipv6_chk_addr (net/ipv6/addrconf.c:2031 net/ipv6/addrconf.c:1972) rds_tcp_laddr_check (net/rds/tcp.c:370) rds_bind (net/rds/bind.c:248) __sys_bind (net/socket.c:1920) __x64_sys_bind (net/socket.c:1956) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68322", "url": "https://ubuntu.com/security/CVE-2026-68322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0); memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT); bind(s, &addr, sizeof(addr)); Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-74579", "url": "https://ubuntu.com/security/CVE-2026-74579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: fix mask build for partial field offload nft_payload_offload_mask() builds the offload match mask for a payload expression that covers only part of a header field. For a partial IPv6 address match (field_len = 16, priv_len = 1) that shift is 1 << 120, which is undefined on the 32-bit int operand. It also trims only one word, so the remaining words stay 0xffffffff (and when priv_len is a multiple of 4 the trim is skipped entirely), leaving the mask covering more bytes than the rule matches. UBSAN: shift-out-of-bounds in net/netfilter/nft_payload.c:278:20 shift exponent 120 is too large for 32-bit type 'int' ... The match is byte-granular and struct nft_data is zero-initialised, so the correct mask is simply the first priv_len bytes set to 0xff. Set those bytes directly and drop the word/shift trimming; this removes the undefined shift and no longer over-masks the trailing bytes.", "cve_priority": "medium", "cve_public_date": "2026-08-17 06:19:00 UTC" }, { "cve": "CVE-2026-74564", "url": "https://ubuntu.com/security/CVE-2026-74564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74566", "url": "https://ubuntu.com/security/CVE-2026-74566", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: make keyring key-chunk byte order agree with keyring_diff_objects() keyring_get_key_chunk() loads description bytes into the index chunk low address first, while keyring_diff_objects() numbers the first differing bit from the low end and folds the absolute byte index into the level without removing the inline-prefix offset the level already carries. The two disagree on byte order and bit position, so the array can be told two keys first differ at a bit that does not differ in the chunk the walker uses, letting crafted descriptions collide into one node. Load the chunk in the order keyring_diff_objects() assumes and drop the inline-prefix length when folding the byte index into the level. This only changes the in-memory ordering used to place keys within a keyring; add, search and read of non-colliding keys are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74567", "url": "https://ubuntu.com/security/CVE-2026-74567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: fix out-of-bounds read in keyring_get_key_chunk() For description-level chunks keyring_get_key_chunk() advances the read pointer by level * sizeof(long) past the inline prefix but only bounds-checks the prefix, so a long enough key description is read past its kmemdup(desc, desc_len + 1) allocation. Compute the full byte offset and bounds-check the description against it before reading. The walk only reaches a description-level chunk when two keys collide through the hash, x, type and domain_tag chunks, so this is reached from an unprivileged add_key(2) with a crafted pair of same-type keys whose index hashes collide; KASAN reports a slab-out-of-bounds read.", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-74569", "url": "https://ubuntu.com/security/CVE-2026-74569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in sip_help_tcp() sip_help_tcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16_MAX while the packet stays under the 65535 enlarge_skb() limit: nf_nat_sip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and \"datalen = datalen + diff - msglen\" yields a huge unsigned datalen, so the next iteration's ct_sip_get_header() reads past the linearized skb tail. Widen diff, tdiff and the seq_adjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nf_ct_seqadj_set() takes s32), so no previously accepted input is rejected. BUG: KASAN: use-after-free in ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ct_sip_get_header (net/netfilter/nf_conntrack_sip.c:464) sip_help_tcp (net/netfilter/nf_conntrack_sip.c:1694) nf_confirm (net/netfilter/nf_conntrack_proto.c:183) nf_hook_slow (net/netfilter/core.c:619) ip6_output (net/ipv6/ip6_output.c:246) ip6_forward (net/ipv6/ip6_output.c:690) ipv6_rcv (net/ipv6/ip6_input.c:351) __netif_receive_skb_one_core (net/core/dev.c:6212) process_backlog (net/core/dev.c:6676) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ...", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-43491", "url": "https://ubuntu.com/security/CVE-2026-43491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum server registration per node Current code does no bound checking on the number of servers added per node. A malicious client can flood NEW_SERVER messages and exhaust memory. Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEW_SERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtr_ns_worker(). Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-74577", "url": "https://ubuntu.com/security/CVE-2026-74577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mpls: initialize rtm_tos in mpls_getroute() mpls_getroute() builds the RTM_NEWROUTE reply to an RTM_GETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (alloc_skb(NLMSG_GOODSIZE, ...)). It sets every field of the header except rtm_tos: \tr = nlmsg_data(nlh); \tr->rtm_family\t = AF_MPLS; \tr->rtm_dst_len\t= 20; \tr->rtm_src_len\t= 0; \tr->rtm_table\t= RT_TABLE_MAIN; \tr->rtm_type\t= RTN_UNICAST; \tr->rtm_scope\t= RT_SCOPE_UNIVERSE; \tr->rtm_protocol = rt->rt_protocol; \tr->rtm_flags\t= 0; struct rtmsg has no padding, so the one uninitialised byte rtm_tos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mpls_dump_route(), which fills the very same header and does set rtm_tos = 0. Initialize rtm_tos to 0, matching mpls_dump_route(). Reproduced with KMSAN by adding an MPLS route and issuing a non-RTM_F_FIB_MATCH RTM_GETROUTE for its label: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x36c/0x33f0 _copy_to_iter+0x36c/0x33f0 __skb_datagram_iter+0x196/0x12c0 skb_copy_datagram_iter+0x5b/0x210 netlink_recvmsg+0x37b/0xef0 ... Uninit was created at: __alloc_skb+0x8ca/0x10e0 mpls_getroute+0x1280/0x3a40 rtnetlink_rcv_msg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized (byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtm_tos)", "cve_priority": "medium", "cve_public_date": "2026-08-15 13:18:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64543", "url": "https://ubuntu.com/security/CVE-2026-64543", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix use-after-free of the discoverer in tipc_disc_rcv() bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(), but tipc_disc_rcv() still dereferences b->disc in RX softirq under rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv). L2 bearers are safe thanks to the synchronize_net() in tipc_disable_l2_media(), but the UDP bearer defers that call to the cleanup_bearer() workqueue, so the discoverer is freed with no grace period: BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149) Read of size 8 at addr ffff88802348b728 by task poc_tipc/184 tipc_disc_rcv (net/tipc/discover.c:149) tipc_rcv (net/tipc/node.c:2126) tipc_udp_recv (net/tipc/udp_media.c:391) udp_rcv (net/ipv4/udp.c:2643) ip_local_deliver_finish (net/ipv4/ip_input.c:241) Freed by task 181: kfree (mm/slub.c:6565) bearer_disable (net/tipc/bearer.c:418) tipc_nl_bearer_disable (net/tipc/bearer.c:1001) The bearer is freed with kfree_rcu(); free the discoverer the same way. Add an rcu_head to struct tipc_discoverer and free it and its skb from an RCU callback. Because the RCU callback (tipc_disc_free_rcu) lives in module text, a call_rcu() that is still pending when the tipc module is unloaded would invoke a freed function. Add an rcu_barrier() to tipc_exit() after the bearer subsystem has been torn down, so all pending discoverer callbacks have run before the module text goes away. Reachable from an unprivileged user namespace: the TIPCv2 genl family is netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC and CONFIG_TIPC_MEDIA_UDP.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72123", "url": "https://ubuntu.com/security/CVE-2026-72123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 (\"can: bcm: use call_rcu() instead of costly synchronize_rcu()\") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a \"scheduling while atomic\" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, which safely cancels both timers and deallocates memory in sleepable process context. A dedicated workqueue is used to prevent system-wide WQ saturation and is cleanly flushed/destroyed on module unload to avoid rmmod page faults. Since the deferred work can now outlive the calling context by an unbounded amount, also take a reference on op->sk when it is assigned and drop it only once the deferred work has cancelled both timers, so a socket can no longer be freed out from under a still-armed timer whose callback (bcm_send_to_user()) dereferences op->sk.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-72019", "url": "https://ubuntu.com/security/CVE-2026-72019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: don't read an unset MAC header in macsec_encrypt() macsec_encrypt() reads the Ethernet header via eth_hdr(skb) (skb->head + skb->mac_header) to memmove() the 12 source/destination MAC bytes forward and make room for the SecTAG. On the AF_PACKET SOCK_RAW + PACKET_QDISC_BYPASS transmit path the skb reaches the macsec ndo_start_xmit() with the MAC header unset, so eth_hdr(skb) resolves to skb->head + (u16)~0 and the read is out of bounds: a 12-byte heap over-read that is also emitted on the wire as the frame's outer source/destination MAC. KASAN reports a slab-out-of-bounds read in macsec_start_xmit() on 6.0; on current mainline a CONFIG_DEBUG_NET build flags it as an unset mac header in skb_mac_header(). On the TX path the L2 header is at skb->data, so use skb_eth_hdr(), added by commit 96cc4b69581d (\"macvlan: do not assume mac_header is set in macvlan_broadcast()\") for exactly this purpose.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-52977", "url": "https://ubuntu.com/security/CVE-2026-52977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B). Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B. Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again. Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead. Tragic. This can be fixed by removing the top most waiter from the list in this case. This allows task B to grab the next top waiter (if any) in the next iteration and make progress. Remove the top most waiter if futex_requeue_pi_prepare() fails. Let the waiter conditionally remove itself from the list in handle_early_requeue_pi_wakeup().", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64535", "url": "https://ubuntu.com/security/CVE-2026-64535", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix potential UAF when ddgst mismatch Shivam Kumar found via vulnerability testing: When data digest is enabled on an NVMe/TCP connection and a digest mismatch occurs on a non-final H2C_DATA PDU during an R2T-based data transfer, the digest error handler in nvmet_tcp_try_recv_ddgst() calls nvmet_req_uninit() — which performs percpu_ref_put() on the submission queue — but does NOT mark the command as completed. It does not set cqe->status, does not modify rbytes_done, and does not clear any flag. When the subsequent fatal error triggers queue teardown, nvmet_tcp_uninit_data_in_cmds() iterates all commands, checks nvmet_tcp_need_data_in() for each one, and finds that the already-uninited command still appears to need data (because rbytes_done < transfer_len and cqe->status == 0). It therefore calls nvmet_req_uninit() a second time on the same command — a double percpu_ref_put against a single percpu_ref_get.", "cve_priority": "critical", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-68480", "url": "https://ubuntu.com/security/CVE-2026-68480", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Make Safe-RET robust against interrupt injection An attacker injecting interrupts while the Safe-RET mitigation executes on machines affected by SRSO can neutralize the safe return sequence, potentially leading to data leakage through speculative execution. Fixup register state as if the Safe-RET sequence executed successfully by \"emulating\" it, in a manner of speaking, and avoid executing a RET instruction after returning from the interrupt.", "cve_priority": "medium", "cve_public_date": "2026-08-06 22:18:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-72282", "url": "https://ubuntu.com/security/CVE-2026-72282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers kvm_io_bus_get_dev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped). Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants. Note that this aligns with other kvm_io_bus*() helpers, which already require the srcu lock to be held by the callers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72068", "url": "https://ubuntu.com/security/CVE-2026-72068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu() update_rlimit_cpu() converts the RLIMIT_CPU value to nanoseconds with u64 nsecs = rlim_new * NSEC_PER_SEC; On 32-bit kernels both rlim_new (unsigned long) and NSEC_PER_SEC (1000000000L) are 32-bit, so the multiplication is performed in unsigned long and truncated for rlim_new > 4 seconds before being widened to u64. The same file already casts to u64 for the matching computation in check_process_timers(): u64 softns = (u64)soft * NSEC_PER_SEC; As a result, the truncated value is installed into the CPUCLOCK_PROF expiry cache (nextevt), causing the process CPU timer to be programmed to fire prematurely for any RLIMIT_CPU soft limit >= 5 seconds. The actual SIGXCPU/SIGKILL decision in check_process_timers() already casts to u64 and is therefore correct, so limit enforcement is not broken; only the expiry-cache programming is wrong. Apply the same cast here so both paths convert rlim_cur identically. 64-bit kernels are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64301", "url": "https://ubuntu.com/security/CVE-2026-64301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: fix of_node refcount leak in scmi_regulator_probe() scmi_regulator_probe() calls of_find_node_by_name() which takes a reference on the returned device node. On the error path where process_scmi_regulator_of_node() fails, the function returns without calling of_node_put() on the child node, leaking the reference. Add of_node_put(np) on the error path to properly release the reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64304", "url": "https://ubuntu.com/security/CVE-2026-64304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - validate RSA CRT component lengths The generic RSA key parser (rsa_helper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt() allocates half-size DMA buffers (key_sz / 2) and right-aligns each component with: memcpy(dst + half_key_sz - len, src, len) When a CRT component is larger than half_key_sz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption. Add a len > half_key_sz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64593", "url": "https://ubuntu.com/security/CVE-2026-64593", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not trim a device which is not writeable [BUG] There is a bug report that btrfs/242 can randomly fail with the following NULL pointer dereference: run fstests btrfs/242 at 2026-06-01 10:25:08 BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609) BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874 BTRFS info (device sdc): using crc32c checksum algorithm BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing BTRFS info (device sdc): allowing degraded mounts BTRFS info (device sdc): turning on async discard BTRFS info (device sdc): enabling free space tree Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000 CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025 pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_trim_fs+0x34c/0xa00 [btrfs] lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs] Call trace: btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P) btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] __arm64_sys_ioctl+0xac/0x108 invoke_syscall.constprop.0+0x5c/0xd0 el0_svc_common.constprop.0+0x40/0xf0 do_el0_svc+0x24/0x40 el0_svc+0x40/0x1d0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1b0/0x1b8 Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00) ---[ end trace 0000000000000000 ]--- Also the reporter is very kind to test the following ASSERT() added to btrfs_trim_free_extents_throttle(): \tASSERT(device->bdev, \t \"devid=%llu path=%s dev_state=0x%lx\\n\", \t device->devid, btrfs_dev_name(device), device->dev_state); And it shows the following output: assertion failed: device->bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82) Which means the device->bdev is NULL, and the dev_state is BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without BTRFS_DEV_STATE_WRITEABLE flag set. [CAUSE] The pc points to the following call chain: btrfs_trim_fs() |- btrfs_trim_free_extents() |- btrfs_trim_free_extents_throttle() |- bdev_max_discard_sectors(device->bdev) So the NULL pointer dereference is caused by device->bdev being NULL. This looks impossible by a quick glance, as just before calling btrfs_trim_free_extents_throttle(), we have skipped any device that has BTRFS_DEV_STATE_MISSING flag set. However in this particular case, there is a window where the missing device is later re-scanned, causing btrfs to remove the BTRFS_DEV_STATE_MISSING flag: btrfs_control_ioctl() |- btrfs_scan_one_device() |- device_list_add() |- rcu_assign_pointer(device->name, name); | This updates the missing device's path to the new good path. | |- clear_bit(BTRFS_DEV_STATE_MISSING, &device->dev_state) This removes the BTRFS_DEV_STATE_MISSING flag. This allows the missing device to re-appear and clear the BTRFS_DEV_STATE_MISSING flag. However the device still does not have the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated. The bdev pointer remains NULL, triggering the crash later. [FIX] This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and device->bdev pointer, and shows a gap in btrfs's re-appearing-device handling. The proper handling of re-appearing device will need quite some extra work, which is out of the context of this small ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64594", "url": "https://ubuntu.com/security/CVE-2026-64594", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: initialize reset_work at allocation time ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on ffs->reset_work when a functionfs instance is unmounted: \tffs_data_reset(ffs); \tcancel_work_sync(&ffs->reset_work); However ffs->reset_work is only ever initialized via INIT_WORK() in ffs_func_set_alt() and ffs_func_disable(), and only on the FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed() when the instance is mounted with the \"no_disconnect\" option, so for the common case (no \"no_disconnect\", or mounted and unmounted without ever being deactivated) reset_work is never initialized. ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch it either, so reset_work.func is left NULL. cancel_work_sync() on such a work then trips the WARN_ON(!work->func) guard in __flush_work(): WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flush_work cancel_work_sync ffs_fs_kill_sb [usb_f_fs] deactivate_locked_super deactivate_super cleanup_mnt __cleanup_mnt task_work_run exit_to_user_mode_loop el0_svc On older kernels cancel_work_sync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization. Initialize reset_work once in ffs_data_new() so it is always valid for the lifetime of the ffs_data, and drop the now-redundant INIT_WORK() calls from the two deactivation paths.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68456", "url": "https://ubuntu.com/security/CVE-2026-68456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect() ueagle-atm uses the asynchronous request_firmware_nowait() in .probe(), but does not wait for its completion, not even in .disconnect(); so, if the device is unplugged meanwhile, its teardown runs concurrently with that. Even though this inconsistency is worth addressing on its own, it has also triggered several bug reports in syzbot over the years (some auto-closed) where the firmware sysfs fallback mechanism (CONFIG_FW_LOADER_USER_HELPER) creates a firmware subdirectory in the device directory during its removal, which might hit unexpected conditions in kernfs, apparently, depending at which point the add and remove operations raced. (See links.) The pattern is: usb ?-?: Direct firmware load for ueagle-atm/eagle?.fw failed with error -2 usb ?-?: Falling back to sysfs fallback for: ueagle-atm/eagle?.fw Call trace: ... kernfs_create_dir_ns sysfs_create_dir_ns create_dir kobject_add_internal kobject_add_varg kobject_add class_dir_create_and_add get_device_parent device_add fw_load_sysfs_fallback fw_load_from_user_helper firmware_fallback_sysfs _request_firmware request_firmware_work_func ... (Some variations are observed, after fw_load_sysfs_fallback(), e.g., [1].) While the kernfs side is being looked at, the ueagle-atm side can be fixed by waiting for the pre-firmware load in the .disconnect() handler. This change has a similar approach to previous work by Andrey Tsygunka [2] (wait_for_completion() in .disconnect()), but it is relatively different in design/implementation; using the Originally-by tag for credit assignment. This has been tested with: - synthetic reproducer to check the error path; - USB gadget (virtual device) to check the firmware upload path; - QEMU device emulator to check the device ID re-enumeration path; (The latter two were written by Claude; no other code/text in this commit.) Links (year first reported): 2025 https://syzbot.org/bug?extid=ce1e5a1b4e086b43e56d 2025 https://syzbot.org/bug?extid=9af8471255ac36e34fd4 2024 https://syzbot.org/bug?extid=306212936b13e520679d 2023 https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 2022 https://syzbot.org/bug?extid=782984d6f1701b526edb 2021 https://syzbot.org/bug?id=f3f221579f4ef7e9691281f3c6f56c05f83e8490 2021 https://syzbot.org/bug?id=84d86f0d71394829df6fc53daf6642c045983881 2021 https://syzbot.org/bug?id=3302dc1c0e2b9c94f2e8edb404eabc9267bc6f90 [1] https://syzkaller.appspot.com/bug?extid=457452d30bcdda75ead2 [2] https://lore.kernel.org/lkml/20250410093146.3776801-2-aitsygunka@yandex.ru/", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:17:00 UTC" }, { "cve": "CVE-2026-64329", "url": "https://ubuntu.com/security/CVE-2026-64329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled. The probe error path already orders free_irq() before ucsi_destroy(). This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64352", "url": "https://ubuntu.com/security/CVE-2026-64352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Allow LPM map access from sleepable BPF programs trie_lookup_elem() annotates its rcu_dereference_check() walks with only rcu_read_lock_bh_held(). Because rcu_dereference_check(p, c) resolves to \"c || rcu_read_lock_held()\", this passes for XDP/NAPI and classic RCU readers but fails for sleepable BPF programs, which enter via __bpf_prog_enter_sleepable() and hold only rcu_read_lock_trace(). trie_update_elem() and trie_delete_elem() have the same problem in a different form: they walk the trie with plain rcu_dereference(), which asserts rcu_read_lock_held() unconditionally. Both are reachable from sleepable BPF programs via the bpf_map_update_elem / bpf_map_delete_elem helpers, and from the syscall path under classic rcu_read_lock(). In the writer paths the trie is actually protected by trie->lock (an rqspinlock taken across the walk); we never relied on the RCU read-side lock to keep nodes alive there. A sleepable LSM hook that ends up touching an LPM trie therefore triggers lockdep on debug kernels: ============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0}, at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64 This is lockdep-only -- no UAF, since Tasks Trace RCU does serialize against the trie's reclaim path -- but it spams the console once per distinct callsite on every debug kernel running a sleepable BPF LSM that touches an LPM trie, which is increasingly common. For the lookup path, switch the rcu_dereference_check() annotation from rcu_read_lock_bh_held() to bpf_rcu_lock_held(), which accepts all three contexts (classic, BH, Tasks Trace). Other map types already follow this convention. For trie_update_elem() and trie_delete_elem(), annotate the walks as rcu_dereference_protected(*p, 1) -- matching trie_free() in the same file -- since trie->lock is held across the walk. rqspinlock has no lockdep_map, so the predicate degenerates to '1' rather than lockdep_is_held(&trie->lock); the protection is real but not machine-verifiable. trie_get_next_key() also uses bare rcu_dereference() but is reachable only from the BPF syscall, which holds classic rcu_read_lock() before dispatching, so it is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64355", "url": "https://ubuntu.com/security/CVE-2026-64355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject fragmented frames in devmap Devmap broadcast redirects clone the packet for all but the last destination. For native XDP, that clone path copies only the linear xdp_frame data, while fragmented frames keep skb_shared_info in tailroom outside the linear area. Cloning such a frame leaves XDP_FLAGS_HAS_FRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skb_shared_info, leading to an out-of-bounds access during frame return. Reject fragmented native XDP frames in dev_map_enqueue_clone(). Add the same restriction to the generic XDP clone path in dev_map_redirect_clone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64361", "url": "https://ubuntu.com/security/CVE-2026-64361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length check_and_correct_requested_length() compares (off + len) against node_size using u32 arithmetic. When the caller passes a large len value (e.g. from an underflowed subtraction in hfs_brec_remove()), off + len can wrap past 2^32 and produce a small result, causing the bounds check to pass when it should fail. For example, with off=14 and len=0xFFFFFFF2 (underflowed from data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6, which is less than a typical node_size of 512, so the check passes and the subsequent memmove reads ~4GB past the node buffer. Fix this by widening the addition to u64 before comparing against node_size. This prevents the u32 wrap while keeping the logic straightforward.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64363", "url": "https://ubuntu.com/security/CVE-2026-64363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: appleir: fix UAF on pending key_up_timer in remove() appleir_remove() runs hid_hw_stop() before timer_delete_sync(). hid_hw_stop() synchronously unregisters the HID input device via hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(), which drops the last reference and frees the underlying input_dev when no userspace handle holds it open. key_up_tick() reads appleir->input_dev and calls input_report_key() / input_sync() on it. The timer is armed from appleir_raw_event() with a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a key was pressed shortly before the device is disconnected, the timer can fire after hid_hw_stop() has freed input_dev but before the teardown drains it. A simple reorder is not sufficient. Putting the timer drain first still leaves a window where a USB URB completion (raw_event) running during hid_hw_stop() can call mod_timer() and re-arm the timer, which then fires after hidinput_disconnect() has freed input_dev. The same URB-completion window also lets raw_event() reach key_up(), key_down() and battery_flat() directly, all of which dereference appleir->input_dev. Introduce a 'removing' flag on struct appleir, gated by the existing spinlock. appleir_remove() sets the flag under the lock and then shuts down the timer with timer_shutdown_sync(), which both drains any in-flight callback and permanently disables further mod_timer() calls. appleir_raw_event() and key_up_tick() bail out early if the flag is set, so no path can arm or run the timer, or dereference appleir->input_dev, after remove() has started tearing down. The keyrepeat and flatbattery branches of appleir_raw_event() previously called into the input layer without holding the spinlock; take it now so the flag check is well-defined. This incidentally closes a pre-existing read-side race on appleir->current_key in the keyrepeat branch. This bug is structurally a sibling of commit 4db2af929279 (\"HID: appletb-kbd: fix UAF in inactivity-timer cleanup path\") and has been present since the driver was introduced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64371", "url": "https://ubuntu.com/security/CVE-2026-64371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (part 1) Fix the easy cases where procfs currently calls ptrace_may_access() without exec_update_lock protection, where the fix is to simply add the extra lock or use mm_access(): - do_task_stat(): grab exec_update_lock - proc_pid_wchan(): grab exec_update_lock - proc_map_files_lookup(): use mm_access() instead of get_task_mm() - proc_map_files_readdir(): use mm_access() instead of get_task_mm() - proc_ns_get_link(): grab exec_update_lock - proc_ns_readlink(): grab exec_update_lock", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64364", "url": "https://ubuntu.com/security/CVE-2026-64364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: fix out-of-bounds bit access on mt_io_flags mt_io_flags is a single unsigned long, but mt_process_slot(), mt_release_pending_palms() and mt_release_contacts() use it as a per-slot bitmap indexed by the slot number. That slot number is only bounded by td->maxcontacts, which is taken from the device's ContactCountMaximum feature report and can be up to 255, not by BITS_PER_LONG. As a result, a multitouch device that advertises a large contact count makes set_bit()/clear_bit() operate past the mt_io_flags word and corrupt the adjacent members of struct mt_device. The sticky-fingers release timer is the easiest way to reach this. mt_release_contacts() runs \tfor (i = 0; i < mt->num_slots; i++) \t\tclear_bit(i, &td->mt_io_flags); with num_slots == maxcontacts. For maxcontacts around 250 the loop clears the bits that overlap td->applications.next, zeroing that list head, and the list_for_each_entry() that immediately follows then dereferences NULL. The kernel panics from timer (softirq) context. On a KASAN build this shows up as a general protection fault in mt_release_contacts() with a null-ptr-deref at offset 0x58, which is offsetof(struct mt_application, num_received). The state is reachable from an untrusted USB or Bluetooth HID multitouch device; no local privileges are required. Store the per-slot active state in a separately allocated bitmap sized for maxcontacts, the same pattern already used for pending_palm_slots, and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two \"mt_io_flags & MT_IO_SLOTS_MASK\" arming checks become bitmap_empty(td->active_slots, td->maxcontacts). Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the same commit to leave the low byte for the slot bits; with the slot bits gone it fits in bit 0 again, which also keeps it within the unsigned long on 32-bit.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64375", "url": "https://ubuntu.com/security/CVE-2026-64375", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: proc: protect ptrace_may_access() with exec_update_lock (FD links) proc_pid_get_link() and proc_pid_readlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways. To fix it, pass the task to the ->proc_get_link() handler, and instead of proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that looks up and locks the task, does the access check, and calls ->proc_get_link().", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64390", "url": "https://ubuntu.com/security/CVE-2026-64390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: track the connection owning a byte-range lock SMB2_LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llist_lock. With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbd_lock and struct file_lock objects. Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llist_lock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-31610", "url": "https://ubuntu.com/security/CVE-2026-31610", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc The kernel ASN.1 BER decoder calls action callbacks incrementally as it walks the input. When ksmbd_decode_negTokenInit() reaches the mechToken [2] OCTET STRING element, ksmbd_neg_token_alloc() allocates conn->mechToken immediately via kmemdup_nul(). If a later element in the same blob is malformed, then the decoder will return nonzero after the allocation is already live. This could happen if mechListMIC [3] overrunse the enclosing SEQUENCE. decode_negotiation_token() then sets conn->use_spnego = false because both the negTokenInit and negTokenTarg grammars failed. The cleanup at the bottom of smb2_sess_setup() is gated on use_spnego: \tif (conn->use_spnego && conn->mechToken) { \t\tkfree(conn->mechToken); \t\tconn->mechToken = NULL; \t} so the kfree is skipped, causing the mechToken to never be freed. This codepath is reachable pre-authentication, so untrusted clients can cause slow memory leaks on a server without even being properly authenticated. Fix this up by not checking check for use_spnego, as it's not required, so the memory will always be properly freed. At the same time, always free the memory in ksmbd_conn_free() incase some other failure path forgot to free it.", "cve_priority": "medium", "cve_public_date": "2026-04-24 15:16:00 UTC" }, { "cve": "CVE-2026-64380", "url": "https://ubuntu.com/security/CVE-2026-64380", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: harden POSIX SID length parsing posix_info_sid_size() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64379", "url": "https://ubuntu.com/security/CVE-2026-64379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: mask server-provided mode to 07777 in modefromsid When modefromsid is active, parse_dacl() applies the server-provided sub_auth[2] value from the NFS mode SID to cf_mode without masking to 07777. Apply the correct masking, same as in the read path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64401", "url": "https://ubuntu.com/security/CVE-2026-64401", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: resolve SWN tcon from live registrations cifs_swn_notify() looks up a witness registration by id under cifs_swnreg_idr_mutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifs_get_swn_reg() lets multiple tcons for the same net/share name share one registration id. A same-share second mount can keep the cifs_swn_reg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tc_lock or incrementing tc_count through swnreg->tcon only moves the use-after-free earlier. Taking tc_lock while holding cifs_swnreg_idr_mutex also violates the documented CIFS lock order. Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifs_swnreg_idr_mutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifs_tcp_ses_lock -> tc_lock order. The notification path uses that pinned tcon directly and drops the reference when done. Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifs_swn_unregister() while the registration is still protected by cifs_swnreg_idr_mutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings. This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENT_MOVE ordering for the representative tcon because the old-IP unregister is sent before cifs_swn_register() sends the new-IP register.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64381", "url": "https://ubuntu.com/security/CVE-2026-64381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix next buffer leak in receive_encrypted_standard() receive_encrypted_standard() allocates next_buffer before checking whether the number of compound PDUs already reached MAX_COMPOUND. If the limit check fails, the function returns immediately and the newly allocated next_buffer is not assigned to server->smallbuf/server->bigbuf, making it leaked. Move the MAX_COMPOUND check before allocating next_buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64206", "url": "https://ubuntu.com/security/CVE-2026-64206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64413", "url": "https://ubuntu.com/security/CVE-2026-64413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: zero chainstack array sashiko reports: looking at ebtables table translation, could a sparse cpu_possible_mask lead to an uninitialized pointer free? If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1]. Not a real-world bug, such allocation isn't expected to fail in the first place.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64428", "url": "https://ubuntu.com/security/CVE-2026-64428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: sch: use raw_spinlock_t in the irq startup path sch_irq_unmask() enables the GPIO IRQ and then updates the controller state through sch_irq_mask_unmask(), which takes sch->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sch_irq_unmask() -> sch_irq_mask_unmask() carrier and used the original spin_lock_irqsave(&sch->lock) edge. Lockdep reported: BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the SCH controller lock to raw_spinlock_t. The same lock is also used by the GPIO direction and value callbacks, but those critical sections only update MMIO-backed GPIO registers and do not contain sleepable operations. Keeping this register lock non-sleeping is therefore appropriate for the irqchip callbacks and does not change the GPIO-side locking contract.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64438", "url": "https://ubuntu.com/security/CVE-2026-64438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix VF2PF work teardown race in adf_disable_sriov() The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adf_accel_vf_info). Currently, adf_disable_sriov() destroys per-VF mutexes and frees vf_info without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory. This manifests as a use-after-free when KASAN is enabled: BUG: KASAN: null-ptr-deref in mutex_lock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qat_pf2vf_resp_wq adf_iov_send_resp [intel_qat] Call Trace: kasan_report+0x119/0x140 mutex_lock+0x76/0xe0 adf_gen4_pfvf_send+0xd4/0x1f0 [intel_qat] adf_recv_and_handle_vf2pf_msg+0x290/0x360 [intel_qat] adf_iov_send_resp+0x8c/0xe0 [intel_qat] process_one_work+0x6ac/0xfd0 worker_thread+0x4dd/0xd30 kthread+0x326/0x410 ret_from_fork+0x33b/0x670 Add a PF-local flag, vf2pf_disabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adf_disable_all_vf2pf_interrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vf_info is destroyed. Introduce adf_enable_all_vf2pf_interrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64441", "url": "https://ubuntu.com/security/CVE-2026-64441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr() Three IE/attribute parsing functions have missing bounds checks. rtw_get_sec_ie() and rtw_get_wapi_ie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtw_get_sec_ie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtw_get_wapi_ie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain. rtw_get_wps_attr() reads wps_ie[0] and wps_ie+2 unconditionally at entry, before verifying that wps_ielen is large enough to contain the 6-byte WPS IE header (element_id + length + 4-byte OUI). Inside the attribute loop, get_unaligned_be16() is called on attr_ptr and attr_ptr+2 without checking that 4 bytes remain in the buffer. Add a cnt+2 bounds check before each loop body in rtw_get_sec_ie() and rtw_get_wapi_ie(), guard each multi-byte comparison with a minimum IE length requirement, add a wps_ielen < 6 early return in rtw_get_wps_attr(), and add a 4-byte bounds check in its inner loop.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64461", "url": "https://ubuntu.com/security/CVE-2026-64461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix IRQ domain leak when port fails to enable When mtk_pcie_enable_port() fails, mtk_pcie_port_free() removes the port from pcie->ports and frees the port structure. However, the IRQ domains set up earlier by mtk_pcie_init_irq_domain() are never freed. Fix this by refactoring mtk_pcie_irq_teardown() into a per-port helper, mtk_pcie_irq_teardown_port(), and calling it from mtk_pcie_setup() when mtk_pcie_enable_port() fails. Since the IRQ teardown must only happen in the probe error path (during resume, child devices may have active MSI mappings and the NOIRQ context prohibits sleeping locks), mtk_pcie_enable_port() is changed to return an error code so callers can distinguish the two paths and act accordingly. This issue was reported by Sashiko while reviewing the EcoNet EN7528 SoC support series.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64446", "url": "https://ubuntu.com/security/CVE-2026-64446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix heap buffer overflow in rtw_cfg80211_set_wpa_ie() supplicant_ie is a 256-byte array in struct security_priv. The WPA and WPA2 IE copy paths use: memcpy(padapter->securitypriv.supplicant_ie, &pwpa[0], wpa_ielen + 2); where wpa_ielen is the raw IE length field (u8, 0-255). When a local user supplies a connect request via nl80211 with a crafted WPA IE of length 255, wpa_ielen + 2 equals 257, overflowing the 256-byte buffer by one byte into the adjacent last_mic_err_time field. rtw_parse_wpa_ie() does not prevent this: its length consistency check compares *(wpa_ie+1) against (u8)(wpa_ie_len-2), which is (u8)(255) == 255 when wpa_ie_len = 257, so the check passes silently. Add explicit bounds checks for both the WPA and WPA2 paths before the memcpy, rejecting any IE whose total size (wpa_ielen + 2) exceeds the supplicant_ie buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64448", "url": "https://ubuntu.com/security/CVE-2026-64448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: restrict implied bcc[0] exemption to responses without data area smb2_check_message() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received (\"server can return one byte more due to implied bcc[0]\"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present. However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (has_smb2_data_area[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, yet smb2_check_message() still accepts it. The subsequent decoder then reads past the end of the receive buffer. This is reachable during NEGOTIATE and SESSION_SETUP, before the session is established. The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server; both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders are affected: BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x16a7/0x1b00 Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81 CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 asn1_ber_decoder+0x16a7/0x1b00 decode_negTokenInit+0x19/0x30 SMB2_negotiate+0x31d9/0x4c90 cifs_negotiate_protocol+0x1f2/0x3f0 cifs_get_smb_ses+0x93f/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 85: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 0 bytes to the right of allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0) which belongs to the cache cifs_small_rq of size 448 BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x36/0x50 Read of size 329 at addr ffff88800726c678 by task mount.cifs/89 CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1 Call Trace: dump_stack_lvl+0x4e/0x70 print_report+0x157/0x4c9 kasan_report+0xce/0x100 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x36/0x50 decode_ntlmssp_challenge+0x457/0x680 SMB2_sess_auth_rawntlmssp_negotiate+0x6f0/0xcb0 SMB2_sess_setup+0x219/0x4f0 cifs_setup_session+0x248/0xaf0 cifs_get_smb_ses+0xf79/0x17e0 cifs_mount_get_session+0x7f/0x3a0 cifs_mount+0xb4/0xcf0 cifs_smb3_do_mount+0x23a/0x1500 smb3_get_tree+0x3b0/0x630 vfs_get_tree+0x82/0x2d0 fc_mount+0x10/0x1b0 path_mount+0x50d/0x1de0 __x64_sys_mount+0x20b/0x270 do_syscall_64+0xee/0x590 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 93: kmem_cache_alloc_noprof+0x106/0x380 mempool_alloc_noprof+0x116/0x1e0 cifs_small_buf_get+0x31/0x80 allocate_buffers+0x10d/0x2b0 cifs_demultiplex_thread+0x1d5/0x1d50 kthread+0x2c6/0x390 ret_from_fork+0x36e/0x5a0 ret_from_fork_asm+0x1a/0x30 The buggy address is located 120 bytes inside of allocated 448-byte region [ffff88800726c600, ffff88800726c7c0) which belongs to the cache cifs_small_rq of size 448 Restrict the +1 exemption to responses that have no data area, so that it still covers the bcc[0] omission it was meant for. When a data area is present, the +1 discrepancy instead means the reported data length overruns the ---truncated---", "cve_priority": "negligible", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64462", "url": "https://ubuntu.com/security/CVE-2026-64462", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: altera: Fix resource leaks on probe failure The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. [mani: commit log]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64475", "url": "https://ubuntu.com/security/CVE-2026-64475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Release the VGA arbiter client on register_device() failure The re-order in the Fixes commit below displaced vfio_pci_vga_init() as the last failure point of what is now vfio_pci_core_register_device() without introducing an unwind for the VGA arbiter registration. In current kernels this is mostly benign because vfio_pci_set_decode() only uses pci_dev state, but the original failure path could leave a callback with a freed vdev cookie. The stale registration also becomes unsafe again once the callback follows drvdata to the vfio device. Add the required VGA unwind callout.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64488", "url": "https://ubuntu.com/security/CVE-2026-64488", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoa_snd_ctl_add(), which can lead to a NULL pointer dereference. Add NULL checks after snd_ctl_new1() calls and return early if any fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64510", "url": "https://ubuntu.com/security/CVE-2026-64510", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup If acpi_nfit_init() fails after adding the acpi_desc object to the acpi_descs list, that object is never removed from that list because the acpi_nfit_shutdown() devm action is not added for the NFIT device in that case. Next, the acpi_nfit_init() failure causes acpi_nfit_probe() to fail, the acpi_desc object is freed, and a dangling pointer is left behind in the acpi_descs. Any subsequent ACPI Machine Check Exception will trigger nfit_handle_mce() which iterates over acpi_descs and so a use-after-free will occur. Moreover, if acpi_nfit_probe() returns 0 after installing a notify handler for the NFIT device and without allocating the acpi_desc object and setting the NFIT device's driver data pointer, the acpi_desc object will be allocated by acpi_nfit_update_notify() and acpi_nfit_init() will be called to initialize it. Regardless of whether or not acpi_nfit_init() fails in that case, the acpi_nfit_shutdown() devm action is not added for the NFIT device and acpi_desc is never removed from the acpi_descs list. If the acpi_desc object is freed subsequently on driver removal, any subsequent ACPI MCE will lead to a use-after-free like in the previous case. To address the first issue mentioned above, make acpi_nfit_probe() call acpi_nfit_shutdown() directly on acpi_nfit_init() failures and to address the other one, add a remove callback to the driver and make it call acpi_nfit_shutdown(). Also, since it is now possible to pass NULL to acpi_nfit_shutdown() or the acpi_desc object passed to it may not have been initialized, add checks against NULL for acpi_desc and its nvdimm_bus field to that function and make acpi_nfit_unregister() clear the latter after unregistering the NVDIMM bus.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64512", "url": "https://ubuntu.com/security/CVE-2026-64512", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Suppress UBSAN warning caused by field misuse The definition of reg->access_width changes depending on the reg->space_id type. Type ACPI_ADR_SPACE_PLATFORM_COMM uses access_width to indicate the PCC region, which can result in a UBSAN if the value is greater than 4. For example: UBSAN: shift-out-of-bounds in drivers/acpi/cppc_acpi.c:1090:9 shift exponent 32 is too large for 32-bit type 'int' CPU: 61 UID: 0 PID: 1220 Comm: (udev-worker) Not tainted 7.0.10-201.fc44.aarch64 #1 PREEMPT(lazy) Hardware name: To be filled by O.E.M. Call trace: ...(trimming) ubsan_epilogue+0x10/0x48 __ubsan_handle_shift_out_of_bounds+0xdc/0x1e0 cpc_write+0x4d0/0x670 cppc_set_perf+0x18c/0x490 cppc_cpufreq_cpu_init+0x1c8/0x380 [cppc_cpufreq] ... (trimming) Lets fix this by validating the region type, as well as whether access_width has a value. Then since we are returning bit_width directly for ACPI_ADR_SPACE_PLATFORM_COMM, drop the code correcting the size.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68466", "url": "https://ubuntu.com/security/CVE-2026-68466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout lpc32xx_xmit_dma() waits for the DMA completion callback but ignores wait_for_completion_timeout(). A timed out DMA transfer is therefore unmapped and reported as successful to the NAND read/write path. Return -ETIMEDOUT when the completion wait expires. Terminate the DMA channel before unmapping the scatterlist so the timed out transfer cannot continue to access the buffer after the error is returned.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68467", "url": "https://ubuntu.com/security/CVE-2026-68467", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: mchp23k256: use SPI match data for chip caps The driver stores chip capacity information in both the OF match table and the SPI id table. Probe currently uses of_device_get_match_data(), so a non-OF SPI modalias match falls back to mchp23k256_caps even when the SPI id table selected a different part. Use spi_get_device_match_data() so SPI id-table driver_data is consumed when OF match data is absent. This keeps the existing default fallback while avoiding the wrong MTD geometry for id-table-only matches.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68469", "url": "https://ubuntu.com/security/CVE-2026-68469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix permanently busy scans after multiple roam iterations In order for the firmware to sleep, the driver has to confirm a previously received sleep request. The normal sequence of evets goes like this: EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm -> SLEEP -> EVENT_AWAKE -> AWAKE. Before sending the sleep-confirm command, the driver must make sure there are no commands either running or waiting to be completed. mwifiex_ret_802_11_associate() unconditionally sets ps_state = PS_STATE_AWAKE when it processes the association command response, outside of the normal powersave management flow. If EVENT_SLEEP arrives while the association command is in flight, ps_state is PRE_SLEEP when the association command response is parsed, and the forced AWAKE overwrites it. The deferred sleep-confirm is never sent. A subsequent scan_start command is correctly acknowledged, but the firmware doesn't generate scan_result events. The scan request never finishes, and additional requests from userspace fail with -EBUSY. After testing on both IW412 and W8997, I could only trigger the bug on the IW412 and observed the firmwares behave differently. On the IW412 the firmware still sends EVENT_SLEEP while the authentication / association process is ongoing. A W8997 under the same conditions seems to suppress power-save for the duration of the association, so PRE_SLEEP never coincided with the association response even after extended periods of testing using the loops described below (>12hours). On the IW412, the delay between commands that triggers an EVENT_SLEEP was empirically determined to be ~20ms. This delay can naturally occur when the driver is outputting debugging information (debug_mask = 0x00000037), in which situation the busy scans issue is repeatable while running \"test 1)\" as described below. If the delay between commands is less than ~20ms, the firmware stays awake and the issue was not reproducible running the same test. The host_mlme=false path also behaves differently. In this case, the entire authentication / association transaction is executed by one command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit EVENT_SLEEP while the command is running. Remove the assignment so the ps_state is only manipulated in the paths that are related to powersave event handling and on the main workqueue for correct sleep confirmation. The following loop tests were performed (with debugging output enabled): 1) force roaming between two AP's, one 5GHz and one 2.4GHz, same SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s between iterations. 2) force a disconnection to AP 1 and a connection to AP 2, test scan. Use wpa_cli to trigger the connection changes, sleep 2s between iterations. Each test ran in each device for at least 3 hours.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:19:00 UTC" }, { "cve": "CVE-2026-68474", "url": "https://ubuntu.com/security/CVE-2026-68474", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access() spufs_mem_mmap_access() computes the local store offset as address - vma->vm_start, but bounds-checks it against vma->vm_end instead of the local store size. On 64-bit, offset is always well below vma->vm_end, so the clamp never fires and len stays unbounded against the LS_SIZE buffer returned by ctx->ops->get_ls(). Reject offsets at or beyond LS_SIZE and clamp len to the remaining space, mirroring the guard already used by spufs_mem_mmap_fault() and spufs_ps_fault().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68475", "url": "https://ubuntu.com/security/CVE-2026-68475", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: reset: sunxi: fix memory region leak on ioremap failure In sunxi_reset_init(), when ioremap() fails, the memory region obtained via request_mem_region() is not released, leading to a resource leak. Add an err_mem_region label to properly release the memory region before freeing the data structure.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68477", "url": "https://ubuntu.com/security/CVE-2026-68477", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: fix more places with wrong ipv6 transport offsets Sashiko reports for more incorrect IPv6 transport offsets. The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers. Also, provide correct offset of the ICMPV6 header in ip_vs_out_icmp_v6() for correct checksum checks when the IPv6 packet has extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68478", "url": "https://ubuntu.com/security/CVE-2026-68478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: memstick: ms_block: reject a card that reports too many blocks msb_ftl_initialize() computes the zone count from the card block count with no bound: \tmsb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; \t... \tfor (i = 0; i < msb->zone_count; i++) \t\tmsb->free_block_count[i] = MS_BLOCKS_IN_ZONE; msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the init loop past the end too. A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-68479", "url": "https://ubuntu.com/security/CVE-2026-68479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btrtl: validate firmware patch bounds rtlbt_parse_firmware() copies patch_length - 4 bytes before appending the firmware version. A malformed firmware patch shorter than the version field can make this subtraction underflow and turn the copy into an oversized read and write during Bluetooth setup. The existing patch_offset + patch_length check can also wrap on 32-bit architectures. Validate the patch length and range without arithmetic overflow before allocating or copying the patch.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72004", "url": "https://ubuntu.com/security/CVE-2026-72004", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix memory leak in ieee80211_register_hw() If kmemdup() fails while copying supported band structures, the error path jumps to fail_rate. This skips rate_control_deinitialize() and leaks the initialized local->rate_ctrl. Fix this by adding a fail_band label that shares the rate-control cleanup path before falling through to the remaining teardown. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have a suitable mac80211 device/driver combination to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72005", "url": "https://ubuntu.com/security/CVE-2026-72005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: avoid full teardown before work setup in probe rt2x00lib_probe_dev() uses the full rt2x00lib_remove_dev() teardown for all probe failures. However, drv_data allocation and workqueue allocation can fail before intf_work, autowakeup_work and sleep_work have been initialized. Do not enter the full remove path until the probe has reached the point where those work items are set up. Return directly for drv_data allocation failure, and use a small early cleanup path for workqueue allocation failure. This issue was found by our static analysis tool and then confirmed by manual review of rt2x00lib_probe_dev() and rt2x00lib_remove_dev(). The early probe exits should not call a common teardown path that assumes the later work setup has already completed. A QEMU PoC forced alloc_ordered_workqueue() to fail before the work initializers are reached. The resulting fail path entered rt2x00lib_remove_dev(), and DEBUG_OBJECTS reported invalid work drains with rt2x00lib_probe_dev() and rt2x00lib_remove_dev() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72010", "url": "https://ubuntu.com/security/CVE-2026-72010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed Creating a child cpuset where cpuset.mems is never set leads to a div/0 when a VMA mempolicy with MPOL_F_RELATIVE_NODES rebinds in response to a CPU hotplug event. Reproduction steps: 1) Create a cgroup w/ cpuset controls (do not set cpuset.mems) 2) Move the task into the child cpuset 3) Create a VMA mempolicy for that task with MPOL_F_RELATIVE_NODES 4) unplug and hotplug a cpu echo 0 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu1/online 5) mempolicy rebind does a div/0 in mpol_relative_nodemask on the call to __nodes_fold() The cpuset code passes (cs->mems_allowed) which is not guaranteed to have nodes to the rebind routine. Use cs->effective_mems instead, which is guaranteed to have a non-empty nodemask once we reach that code path. [ david: add a comment, slightly rephrase description ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:20:00 UTC" }, { "cve": "CVE-2026-72013", "url": "https://ubuntu.com/security/CVE-2026-72013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent NULL pointer dereference in machine_kexec_prepare() A NULL pointer dereference issue is noticed in riscv's machine_kexec_prepare(), where image->segment[i].buf might be NULL and copied unchecked. The NULL buf comes from ima_add_kexec_buffer(), where kbuf is added by kexec_add_buffer(), but kbuf.buffer is NULL, then it is copied without a check in machine_kexec_prepare(): kexec_file_load -> kimage_file_alloc_init() -> kimage_file_prepare_segments() -> ima_add_kexec_buffer() -> kexec_add_buffer() -> machine_kexec_prepare() -> memcpy() Address this by adding a check before the data copy attempt.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72014", "url": "https://ubuntu.com/security/CVE-2026-72014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drbd: reject data replies with an out-of-range payload size recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an outstanding read request. The peer-supplied payload length reaches it as the signed int data_size, and two peer-controlled inputs can make it negative. With a negotiated data-integrity-alg the digest length is subtracted first, so a reply whose payload is smaller than the digest underflows data_size. With no integrity algorithm (the default) data_size is assigned from the unsigned h95/h100 wire length and drbdd() never bounds it for a payload-carrying command, so a length above INT_MAX casts it negative; this path needs no non-default feature. The bio receive loop then computes expect = min_t(int, data_size, bv_len), which is negative, and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX into the first mapped page. The sibling receive path read_in_block() is not affected: it uses an unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving. Reject a data reply whose size is negative after the optional digest subtraction, covering both triggers. Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen bytes past a bio page in the receiver, corrupting kernel memory. A node that reads from its peer (a diskless node, or read-balancing to the peer) is exposed in the default configuration; data-integrity-alg is not required.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72020", "url": "https://ubuntu.com/security/CVE-2026-72020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: reset full ip_vs_seq structs in ip_vs_conn_new Commit 9a05475cebdd (\"ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new\") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members. That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data. When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow. Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing \"reset struct ip_vs_seq\" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72021", "url": "https://ubuntu.com/security/CVE-2026-72021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in SCTP state lookup set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header. This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed. Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72022", "url": "https://ubuntu.com/security/CVE-2026-72022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: llc: fix SAP refcount leak in llc_ui_autobind() llc_ui_autobind() opens a SAP after choosing a dynamic LSAP. llc_sap_open() returns a reference owned by the caller, and llc_sap_add_socket() takes a second reference for the socket's membership in the SAP hash tables. llc_ui_bind() drops the caller's reference after adding the socket, but llc_ui_autobind() keeps it. When the socket is closed, llc_sap_remove_socket() releases only the socket reference, leaving the SAP on llc_sap_list with sk_count == 0. This is user-visible because repeated autobind and close cycles can consume all dynamic SAP values and make later autobinds fail with -EUSERS. Drop the caller's reference after a successful autobind, matching llc_ui_bind()'s ownership model.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72024", "url": "https://ubuntu.com/security/CVE-2026-72024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: remove interfaces with RCU list deletion Queue wake, stop, and disable paths walk local->interfaces under RCU. The bulk hardware teardown path removes entries with list_del(), so an asynchronous transmit completion can follow a poisoned list node in ieee802154_wake_queue(). Use list_del_rcu() as in the single-interface removal path. The following unregister_netdevice() waits for in-flight RCU readers before freeing the netdevice, so no separate grace-period wait is needed.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72025", "url": "https://ubuntu.com/security/CVE-2026-72025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: s390/monwriter: Reject buffer reuse with different data length When data buffers are reused, e.g. for interval sample records, the first record determines the data length, and the size of the buffer for user copy. Current monwriter code does not check if the data length was changed for subsequent records, which also would never happen for valid user programs. However, a malicious user could change the data length, resulting in out of bounds user copy to the kernel buffer, and memory corruption. By default, the monwriter misc device is created with root-only permissions, so practical impact is typically low. Fix this by checking for changed data length and rejecting such records.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72033", "url": "https://ubuntu.com/security/CVE-2026-72033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: orangefs: keep the readdir entry size 64-bit in fill_from_part() fill_from_part() computes the size of a directory entry in size_t but stores it in a __u32. An entry length near U32_MAX wraps it to a small value, bypasses the bounds check, and is then used to index the entry, reading far past the directory part -- an out-of-bounds read that oopses the kernel. Compute the size as a u64 so it cannot truncate; the bounds check then rejects the entry. The trailer is supplied by the userspace client.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72036", "url": "https://ubuntu.com/security/CVE-2026-72036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_multiq: Replace direct dequeue call with peek and qdisc_dequeue_peeked multiq_dequeue() takes a packet from a band's child with a direct ->dequeue() call after multiq_peek() peeked it. When the child is non-work-conserving the peek stashes the skb in the child's gso_skb, so the direct dequeue returns a different skb and orphans the stash, desyncing the child's qlen/backlog. With a qfq child reached through a peeking parent (e.g. tbf) this re-enters the child on an emptied list and dereferences NULL, panicking the kernel from softirq on ordinary egress. Take the packet through qdisc_dequeue_peeked(), as sch_prio already does and as sch_red and sch_sfb were just fixed to do. The helper is a no-op when the child has no stash, so a work-conserving child is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72038", "url": "https://ubuntu.com/security/CVE-2026-72038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: liquidio: fix BAR resource leak on PF number failure If cn23xx_get_pf_num() fails, the function returns without unmapping either BAR. Unmap both BARs before returning from the error path. Found by manual code review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72039", "url": "https://ubuntu.com/security/CVE-2026-72039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72229", "url": "https://ubuntu.com/security/CVE-2026-72229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: clean untagged VLAN on netdev registration failure When an mesh interface is registered, it creates an untagged struct batadv_meshif_vlan on top of it via the NETDEV_REGISTER notifier. But in this process, another receiver of this notification can veto the registration. The netdev registration will be aborted because of this veto. The register_netdevice() call will try to clean up the net_device using unregister_netdevice_queue() - which only uses the .priv_destructor to free private resources. In this situation, .dellink will not be called. The cleanup of the untagged batadv_meshif_vlan must thefore be done in the destructor to avoid a leak of this object.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72232", "url": "https://ubuntu.com/security/CVE-2026-72232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: ensure minimal ethernet header on TX As documented in commit 8bd67ebb50c0 (\"net: bridge: xmit: make sure we have at least eth header len bytes\"), it is possible by for a local user with eBPF TC hook access to attach a tc filter which truncates the packet and redirects to an batadv interface. But the code assumes that at least ETH_HLEN bytes are available and thus might read outside of the available buffer. The batadv_interface_tx() must therefore always check itself if enough data is available for the ethernet header and don't rely on min_header_len.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72235", "url": "https://ubuntu.com/security/CVE-2026-72235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: retrieve ethhdr after potential skb realloc on RX pskb_may_pull() in batadv_interface_rx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64534", "url": "https://ubuntu.com/security/CVE-2026-64534", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock. Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72047", "url": "https://ubuntu.com/security/CVE-2026-72047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit ca8210_test_int_driver_write() and ca8210_test_int_user_read() exchange a kmalloc'd buffer pointer through a struct kfifo, but pass a literal '4' as the byte count to kfifo_in()/kfifo_out(). This is correct on 32-bit (pointer = 4 bytes), but on 64-bit only the low 4 bytes of the 8-byte pointer are written into the FIFO. The reader then reads back 4 bytes into an 8-byte local pointer variable, leaving the upper 4 bytes uninitialized stack data. The first dereference of the reconstructed pointer (fifo_buffer[1]) accesses an arbitrary kernel address and generally results in an oops. Use sizeof(fifo_buffer) so the byte count matches pointer width on every architecture. The driver has no architecture restriction in Kconfig, so any 64-bit build with CONFIG_IEEE802154_CA8210_DEBUGFS=y is exposed. Issue has been latent since the driver was added in 2017 because it is most commonly deployed on 32-bit MCUs. Found via a custom Coccinelle semantic patch hunting for short-byte kfifo I/O on byte-mode kfifos used to shuttle pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72048", "url": "https://ubuntu.com/security/CVE-2026-72048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: fix cas_ctl leak on spi_async failure ca8210_spi_transfer() allocates cas_ctl with kzalloc_obj(GFP_ATOMIC) and relies entirely on the SPI completion callback ca8210_spi_transfer_complete() to free it. The spi_async() API only invokes the completion callback on successful submission. On failure it returns a negative error code without ever queuing the callback, which leaves cas_ctl and its embedded spi_message and spi_transfer orphaned. Every kfree(cas_ctl) in the driver is inside the completion callback, so there is no other reclamation path. ca8210_spi_transfer() is called from ca8210_spi_exchange(), the interrupt handler ca8210_interrupt_handler(), and from the retry path inside the completion callback itself. The exchange and interrupt handler paths loop on -EBUSY, so under sustained SPI bus contention every retry iteration leaks a fresh cas_ctl (~600 bytes per occurrence). Fix it by freeing cas_ctl on the spi_async() error path. While here, correct the misleading error string: the function calls spi_async(), not spi_sync().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72049", "url": "https://ubuntu.com/security/CVE-2026-72049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: admin-gate legacy LLSEC dump operations In net/ieee802154/netlink.c, the legacy IEEE802154_NL family ops table builds the LLSEC dump entries (LLSEC_LIST_KEY, LLSEC_LIST_DEV, LLSEC_LIST_DEVKEY, LLSEC_LIST_SECLEVEL) with IEEE802154_DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154_CMD_GET_SEC_KEY and friends with .flags = GENL_ADMIN_PERM. Any local uid that can open AF_NETLINK / NETLINK_GENERIC can resolve the \"802.15.4 MAC\" family and dump LLSEC_LIST_KEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154_ATTR_LLSEC_KEY_BYTES, copied verbatim from struct ieee802154_llsec_key.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames. Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSEC_LIST_KEY dump on the legacy IEEE802154_NL generic-netlink family. Introduce IEEE802154_DUMP_PRIV() mirroring IEEE802154_DUMP() but setting .flags = GENL_ADMIN_PERM, and use it for the four LLSEC dump entries. LIST_PHY and LIST_IFACE retain IEEE802154_DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154_CMD_GET_WPAN_PHY and NL802154_CMD_GET_INTERFACE carry \"can be retrieved by unprivileged users\" annotations).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72052", "url": "https://ubuntu.com/security/CVE-2026-72052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink ip6gre_changelink() and ip6erspan_changelink() operate on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate both ops on rtnl_dev_link_net_capable() at their top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72054", "url": "https://ubuntu.com/security/CVE-2026-72054", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink vti_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72055", "url": "https://ubuntu.com/security/CVE-2026-72055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink vti6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate vti6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72056", "url": "https://ubuntu.com/security/CVE-2026-72056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ena: clean up XDP TX queues when regular TX setup fails create_queues_with_size_backoff() creates XDP TX queues before setting up the regular TX path. If the subsequent allocation or creation of regular TX queues fails, the error handling paths omit the teardown of the XDP TX queues, leading to a resource leak. Fix this by explicitly destroying the XDP TX queue subset at the two missing failure points. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc7. An x86_64 allyesconfig build showed no new warnings. As we do not have an ENA device to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72061", "url": "https://ubuntu.com/security/CVE-2026-72061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sit: require CAP_NET_ADMIN in the device netns for changelink ipip6_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72066", "url": "https://ubuntu.com/security/CVE-2026-72066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Bound hotplug states sysfs output states_show() adds CPU hotplug state names into a single sysfs buffer using sprintf(). With enough registered states, this can write past the end of the PAGE_SIZE buffer. Use sysfs_emit_at() so output is bounded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72067", "url": "https://ubuntu.com/security/CVE-2026-72067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpu: hotplug: Preserve per instance callback errors cpuhp_invoke_callback() unwinds earlier callbacks for the same hotplug state when one instance fails. The rollback path currently reuses ret, so a successful rollback can hide the original error and make the failed transition look successful. Keep the rollback result separate from the original error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72074", "url": "https://ubuntu.com/security/CVE-2026-72074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix type confusion in CDC union descriptor parsing The driver currently trusts the bMasterInterface0 from the CDC union descriptor without verifying that it matches the interface being probed. This could lead to the driver overwriting the private data of another interface. Validate that the control interface found in the descriptor is indeed the one we are probing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72076", "url": "https://ubuntu.com/security/CVE-2026-72076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging The debug logging in ims_pcu_irq() unconditionally prints data from pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the control URB exceeds pcu->max_in_size, this leads to an out-of-bounds read. Fix this by printing from the correct buffer associated with the URB.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72078", "url": "https://ubuntu.com/security/CVE-2026-72078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - validate control endpoint type The driver currently assumes that the first endpoint of the control interface is an interrupt IN endpoint without verifying it. A malicious device could provide a different endpoint type, which would then be passed to usb_fill_int_urb(), potentially leading to kernel warnings or undefined behavior. Verify that the control endpoint is an interrupt IN endpoint.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72079", "url": "https://ubuntu.com/security/CVE-2026-72079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix use-after-free and double-free in disconnect ims_pcu_disconnect() only intended to perform cleanup when the primary (control) interface is unbound. However, it currently relies on the interface class to distinguish between control and data interfaces. A malicious device could present a data interface with the same class as the control interface, leading to premature cleanup and potential use-after-free or double-free. Switch to verifying that the interface being disconnected is indeed the control interface.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72081", "url": "https://ubuntu.com/security/CVE-2026-72081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix I/O leak on unsupported additional CDB efct_dispatch_fcp_cmd() allocates an efct_io before dispatching an unsolicited FCP command. If the command has an unsupported additional CDB, the function returns -EIO before handing the IO to the SCSI layer. Free the allocated IO before returning from this error path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72082", "url": "https://ubuntu.com/security/CVE-2026-72082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: efct: Fix refcount leak in efct_hw_io_abort() When efct_hw_reqtag_alloc() fails in efct_hw_io_abort(), the error path returns -ENOSPC without releasing the reference obtained via kref_get_unless_zero() earlier in the function. All other error paths correctly drop the reference. This causes a permanent reference leak on the io_to_abort object. Additionally, the abort_in_progress flag is left set to true on this path, which means future abort attempts for the same I/O will immediately return -EINPROGRESS even though the abort was never submitted, effectively blocking recovery. Fix this by adding the missing kref_put() call and reset abort_in_progress to false, matching the cleanup done in the efct_hw_wq_write() failure path below.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72083", "url": "https://ubuntu.com/security/CVE-2026-72083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE core_scsi3_emulate_pro_register_and_move() maps the PERSISTENT RESERVE OUT parameter list with transport_kmap_data_sg() and parses the destination TransportID with target_parse_pr_out_transport_id(). For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() returns the ISID in iport_ptr as a raw pointer into that mapped buffer. The function then unmaps the buffer with transport_kunmap_data_sg() before dereferencing iport_ptr in strcmp(), __core_scsi3_locate_pr_reg() and core_scsi3_alloc_registration(). When the parameter list spans more than one page (PARAMETER LIST LENGTH > 4096), transport_kmap_data_sg() uses vmap() and transport_kunmap_data_sg() does vunmap(), so the kernel virtual address backing iport_ptr is torn down and every subsequent dereference is a use-after-free read of the unmapped region. Keep the parameter list mapped until iport_ptr is no longer needed: drop the early transport_kunmap_data_sg() and unmap once on the success path, right before returning. The error paths already unmap through the existing \"if (buf) transport_kunmap_data_sg(cmd)\" at the out: label, which now runs on every post-map error exit because buf is no longer cleared early. Only reads of the mapping happen while spinlocks are held; the map and unmap calls remain outside any lock. The sibling caller core_scsi3_decode_spec_i_port() already uses the buffer before unmapping it and is left unchanged.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72084", "url": "https://ubuntu.com/security/CVE-2026-72084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: Bound PR-OUT TransportID parsing to the received buffer core_scsi3_decode_spec_i_port() and core_scsi3_emulate_register_and_move() hand the raw PERSISTENT RESERVE OUT parameter buffer to target_parse_pr_out_transport_id() without telling it how many bytes are valid. For an iSCSI TransportID (FORMAT CODE 01b), iscsi_parse_pr_out_transport_id() locates the \",i,0x\" ISID separator with an unbounded strstr() (and on the error path prints the name with a further unbounded \"%s\"). An initiator can submit a TransportID whose iSCSI name contains neither a \",i,0x\" substring nor a NUL terminator, filling the parameter list to its end, so the scan runs off the end of the buffer. When the parameter list spans more than one page the buffer is a multi-page vmap (transport_kmap_data_sg()), so the over-read walks into the trailing vmalloc guard page and oopses (KASAN: vmalloc-out-of-bounds in strstr). It is reachable by any fabric that delivers a PR OUT to a device exported through an iSCSI TPG, including a guest via vhost-scsi. Pass the number of received bytes down to the parser and validate the iSCSI TransportID's own self-described length (ADDITIONAL LENGTH + 4) once, up front: reject it if it is below the spc4r17 minimum or larger than the received buffer, then bound the separator search, the ISID walk and the name copy by that length. This is the length check the callers already perform after the parse (core_scsi3_decode_spec_i_port() compares tid_len against tpdl, core_scsi3_emulate_register_and_move() validates it against data_length), moved ahead of the scan. Also drop the unbounded \"%s\" of the unterminated name. Add per-format explicit name-length checks before copying into i_str, rather than silently truncating with min_t: for FORMAT CODE 00b reject if the descriptor body (tid_len - 4 bytes) cannot fit in i_str[TRANSPORT_IQN_LEN]; for FORMAT CODE 01b reject if the name portion (from &buf[4] up to the separator) cannot fit. Both checks make the bounds intent explicit at each format branch. While here, also reject a FORMAT CODE 01b TransportID whose \",i,0x\" separator sits at the very end of the descriptor: that leaves an empty ISID and points the returned port nexus pointer at buf + tid_len, one past the descriptor, which the registration code (__core_scsi3_locate_pr_reg(), __core_scsi3_alloc_registration()) then dereferences as the ISID string -- the same over-read of the parameter buffer for a malformed descriptor.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72085", "url": "https://ubuntu.com/security/CVE-2026-72085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free unsubmitted command instead of double-putting it scsiback_get_pend_req() obtains a command tag and returns a vscsibk_pend whose embedded se_cmd has only been memset to 0, so its cmd_kref is 0; the se_cmd is initialised (kref_init() via target_init_cmd()) only later, in scsiback_cmd_exec(), on the successful VSCSIIF_ACT_SCSI_CDB path. The two error paths in scsiback_do_cmd_fn() taken before the command is submitted -- a failed scsiback_gnttab_data_map() and an unknown ring_req.act -- call transport_generic_free_cmd(&pending_req->se_cmd, 0), which kref_put()s a refcount of 0. That underflows it (\"refcount_t: underflow; use-after-free\") and, as the release function is not run, leaks the command tag. Impact: a pvSCSI guest can leak every command tag of a LUN's session, stopping the LUN, by submitting requests with a bad grant reference or an unknown request type; under panic_on_warn the refcount underflow panics the host. Add a helper that just returns the tag with target_free_tag() and sends the error response. It frees the tag while the v2p reference still pins the session, and snapshots the response fields beforehand because freeing the tag can let another ring reuse the pending_req slot.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72086", "url": "https://ubuntu.com/security/CVE-2026-72086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: xen: scsiback: Free the command tag on the TMR submit-failure path scsiback_device_action() obtains a command tag in scsiback_get_pend_req() and submits a task-management request with target_submit_tmr(). When target_submit_tmr() fails it returns < 0 and scsiback jumps to the err: label, which sends a response but frees nothing, leaking the tag. Impact: a pvSCSI guest can leak the command tags of a LUN's session, stopping the LUN, by issuing VSCSIIF_ACT_SCSI_ABORT or RESET requests whenever target_submit_tmr() fails. transport_generic_free_cmd() cannot be used here. By the time target_submit_tmr() returns an error it has already run __target_init_cmd() (so se_cmd->cmd_kref is one, not zero), and on its target_get_sess_cmd() error path it has freed se_cmd->se_tmr_req via core_tmr_release_req() while leaving SCF_SCSI_TMR_CDB set and the pointer dangling. Letting the command release run target_free_cmd_mem() would then double-free se_tmr_req. Use the same helper, which returns just the tag, on this path too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72088", "url": "https://ubuntu.com/security/CVE-2026-72088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path If phys_disk->in_reset is set, the function returns directly without undoing the resources acquired for the command. Add the missing error cleanup by unmapping the IOACCEL2 SG chain block when needed, unmapping the SCSI command, and dropping the outstanding IOACCEL command count before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72102", "url": "https://ubuntu.com/security/CVE-2026-72102", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm_early_create: fix freeing used table on dm_resume failure If dm_resume fails, the kernel attempts to free table with dm_table_destroy, but the table was already instantiated with dm_swap_table. This commit skips the call to dm_table_destroy in this case.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72105", "url": "https://ubuntu.com/security/CVE-2026-72105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm-log: fix a bitset_size overflow on 32bit machines Commit c20e36b7631d (\"dm log: fix out-of-bounds write due to region_count overflow\") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72107", "url": "https://ubuntu.com/security/CVE-2026-72107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix out-of-bounds memory access for non-zero start sector dm-era tracks writes in target-relative blocks, but era_map() calculates the writeset block before applying the target offset. Tables with a non-zero start sector can therefore pass an absolute mapped-device block to metadata_current_marked(). If the absolute block is beyond the current writeset size, writeset_marked() tests past the end of the in-core bitset. KASAN reports this as a vmalloc-out-of-bounds access. Apply the target offset before calculating the era block so writeset lookups use the target-relative block number.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72108", "url": "https://ubuntu.com/security/CVE-2026-72108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm thin metadata: fix metadata snapshot consistency on commit failure __reserve_metadata_snap() and __release_metadata_snap() modify the superblock's held_root directly in the block_manager's buffer. If the subsequent metadata commit fails, the held_root gets flushed to disk through the abort_transaction path, resulting in inconsistent metadata. Reproducer 1: __reserve_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 14th block inaccessible, to trigger metadata commit failure in the subsequent reserve_metadata_snap operation. The 14th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 112 linear /dev/sdc 0 112 3984 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Take a metadata snapshot to trigger metadata commit failure and transaction abort. However, the held_root is written to disk, breaking metadata consistency. dmsetup message tpool 0 \"reserve_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 2, but space map contains 1. Bad reference count for metadata block 7. Expected 2, but space map contains 1. Bad reference count for metadata block 13. Expected 1, but space map contains 0. Reproducer 2: __release_metadata_snap() 1. Create a 2 MiB metadata device and make the region after the 16th block inaccessible, to trigger metadata commit failure in the subsequent release_metadata_snap operation. The 16th block will be the shadow destination for the index block. dmsetup create tmeta --table \"0 128 linear /dev/sdc 0 128 3968 error\" 2. Create a 16 MiB thin-pool dmsetup create tdata --table \"0 32768 zero\" dd if=/dev/zero of=/dev/mapper/tmeta bs=4k count=1 dmsetup create tpool --table \"0 32768 thin-pool /dev/mapper/tmeta \\ /dev/mapper/tdata 128 0 1 skip_block_zeroing\" 3. Reserve then release the metadata snapshot, to trigger metadata commit failure and transaction abort. The held_root gets removed from the on-disk superblock, causing inconsistent metadata. dmsetup message tpool 0 \"reserve_metadata_snap\" dmsetup message tpool 0 \"release_metadata_snap\" thin_check v1.2.2 result: Bad reference count for metadata block 6. Expected 1, but space map contains 2. Bad reference count for metadata block 7. Expected 1, but space map contains 2. 1 metadata blocks have leaked. Fix by deferring the held_root update to commit time. Additionally, move the existing-snapshot check in __reserve_metadata_snap before the shadow operation to avoid unnecessary work. In __release_metadata_snap, clear pmd->held_root before btree deletion so partial failure leaks blocks rather than leaving a stale reference, and unlock the snapshot block before decrementing its refcount.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72109", "url": "https://ubuntu.com/security/CVE-2026-72109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sparx5: unregister blocking notifier on init failure sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72120", "url": "https://ubuntu.com/security/CVE-2026-72120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing rcu list annotations and operations sashiko-bot remarked the missing use of list_add_rcu() in bcm_[rx|tx]_setup() to have a proper initialized bcm_op structure when bcm_proc_show() traverses the bcm_op's under rcu_read_lock(). To cover all initial settings of the bcm_op's the list_add_rcu() calls are moved to the end of the setup code. While at it, also fix the mirroring removal side: bcm_release() called bcm_remove_op() - which frees the op via call_rcu() - on ops that were still linked in bo->tx_ops/bo->rx_ops, without list_del_rcu() first. Unlink each op with list_del_rcu() before handing it to bcm_remove_op(), matching the existing pattern in bcm_delete_tx_op()/bcm_delete_rx_op().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72122", "url": "https://ubuntu.com/security/CVE-2026-72122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure bcm_sendmsg() reads bo->ifindex and checks bo->bound before taking lock_sock(), while bcm_notify(), bcm_connect() and bcm_release() all mutate both fields under that same lock. Because the lockless reads and the locked writes are unordered with respect to each other, a racing bcm_notify() (device unregister) or bcm_connect() (concurrent bind on another thread sharing the socket) can make bcm_sendmsg() observe an inconsistent combination, e.g. a stale bound=1 together with the now-cleared ifindex=0, silently turning a socket bound to a specific CAN interface into one that also matches \"any\" interface. Keep the lockless bo->bound check purely as a fast-path reject, and move the ifindex read (and a bo->bound re-check) into the locked section, where every writer already serializes. This removes the possibility of observing the two fields torn against each other, rather than trying to fix it with more READ_ONCE()/WRITE_ONCE() pairs on two independently updated fields. Annotate the now-purely-lockless bo->bound accesses consistently across all its write sites. Also fix bcm_rx_setup() silently returning success when the target device disappears concurrently instead of reporting -ENODEV, so a broken RX op is no longer left registered as if it had succeeded.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72126", "url": "https://ubuntu.com/security/CVE-2026-72126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: use unconditional synchronize_rcu() in isotp_release() isotp_notify() unregisters the (RCU) CAN filters via can_rx_unregister() and clears so->bound without waiting for a grace period. isotp_release() uses so->bound to decide whether it needs to call synchronize_rcu() before cancelling so->rxtimer, so when NETDEV_UNREGISTER runs first it skips that synchronize_rcu() and can cancel the timer while an in-flight isotp_rcv() is still executing and about to re-arm it via isotp_send_fc(), leading to a use-after-free timer callback on the freed socket. sakisho-bot remarked a problem with rtnl_lock held in isotp_notify(), therefore make isotp_release() always call synchronize_rcu() before cancelling the timers, regardless of so->bound. This still closes the original race (isotp_notify() clearing so->bound without waiting for in-flight isotp_rcv() callers before isotp_release() cancels the RX timer) without adding any RCU wait to the netdevice notifier path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72129", "url": "https://ubuntu.com/security/CVE-2026-72129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: handle inline data with a nonzero offset nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inline_data_size, but the mapping still assumes the data begins in the first inline page: \tsg->offset = off; \tsg->length = min_t(int, len, PAGE_SIZE - off); When a port is configured with inline_data_size > PAGE_SIZE (settable up to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size] makes \"PAGE_SIZE - off\" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. num_pages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist. Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from page_off + len. Because the request scatterlist may now start at inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL identity test in nvmet_rdma_release_rsp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmet_req_free_sgls() frees an inline page (and warns in free_large_kmalloc()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64551", "url": "https://ubuntu.com/security/CVE-2026-64551", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: \terr = (struct sctp_errhdr *)(chunk->skb->data); \tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72133", "url": "https://ubuntu.com/security/CVE-2026-72133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: uniphier: Fix completion initialization order before devm_request_irq() The driver calls devm_request_irq() before initializing the completion used by the interrupt handler. Because the interrupt may occur immediately after devm_request_irq(), the handler may execute before init_completion(). This may result in calling complete() on an uninitialized completion, causing undefined behavior. This has been observed with KASAN. Fix this by initializing the completion before registering the IRQ.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72135", "url": "https://ubuntu.com/security/CVE-2026-72135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Make the TPM character devices non-seekable The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled. After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset(). Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale. Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged. Tested on Linux 6.12 with KASAN and a swtpm TPM2 device: - sequential partial reads returned the complete response - pread() and preadv() with offset 0x1400 returned -ESPIPE - pwrite() and pwritev() with offset zero returned -ESPIPE - the pending response remained intact after the rejected operations - a subsequent normal command/response cycle completed normally - no KASAN report was produced.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72136", "url": "https://ubuntu.com/security/CVE-2026-72136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for changelink xfrmi_changelink() operates on at most two netns, dev_net(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net. Gate xfrmi_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72138", "url": "https://ubuntu.com/security/CVE-2026-72138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: fix error handling in ioctl When gntdev_ioctl_map_grant_ref() fails to copy the operation result back to userspace after successfully adding the mapping to the list, the error path returns -EFAULT without releasing the reference acquired by gntdev_alloc_map(). The mapping remains in priv->maps with a refcount of 1, causing a memory leak and a dangling list entry. Additionally, gntdev_add_map() may modify map->index to avoid overlap with existing mappings. Therefore, the index returned to userspace must be obtained after gntdev_add_map() completes. Fix this by holding the mutex across gntdev_add_map(), retrieving the correct index, and copy_to_user(). If copy_to_user() fails, remove the mapping from the list and release the reference while still holding the lock. Fix these issues by properly handling all error cases.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72140", "url": "https://ubuntu.com/security/CVE-2026-72140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource() If devm_platform_get_and_ioremap_resource() returns an error, mlxbf_i2c_init_resource() frees tmp_res before reading tmp_res->io to get the error code. This results in a use-after-free. Save the error code before freeing tmp_res.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72153", "url": "https://ubuntu.com/security/CVE-2026-72153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/crossbar: Use correct index in crossbar_domain_free() crossbar_domain_free() resets the domain data and then uses the nulled out irq_data->hwirq member as index to reset the irq_map[] entry and to write the relevant crossbar register with a safe entry. That means it never frees the correct index and keeps the crossbar register connection to the source interrupt active. If it would not reset the domain data, then this would be even worse as irq_data->hwirq holds the source interrupt number, but both the map and register index need the corresponding GIC SPI number and not the source interrupt number. This might even result in an out of bounds access as the source interrupt number can be higher than the maximal index space. Fix this by using the GIC SPI index from the parent domain's irq_data.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72159", "url": "https://ubuntu.com/security/CVE-2026-72159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject non-inline dinodes with i_size and zero i_clusters On a volume mounted without OCFS2_FEATURE_INCOMPAT_SPARSE_ALLOC, a non-inline regular file with non-zero i_size and zero i_clusters is structurally malformed: the extent map declares no allocated clusters yet the size header claims content exists. Keep rejecting that shape, but express it through a shared predicate so the same invariant is available to normal inode reads and online filecheck. The same zero-cluster shape is also malformed for non-inline directories. ocfs2 directory growth allocates backing storage before advancing i_size, and ocfs2_dir_foreach_blk_el() later walks until ctx->pos reaches i_size_read(inode). A forged directory dinode with a huge i_size and no clusters would repeatedly fail on holes while advancing through the claimed size. Sparse regular files remain exempt: on sparse-alloc volumes, truncate can legitimately grow i_size without allocating clusters. System inodes and inline-data dinodes also retain their separate storage rules. Mirror the check in ocfs2_filecheck_validate_inode_block() as well. filecheck reports through its own error namespace, so malformed size/cluster state is logged as a filecheck invalid-inode result rather than via ocfs2_error(), but it must not proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72160", "url": "https://ubuntu.com/security/CVE-2026-72160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject dinodes with non-canonical i_mode type Patch series \"ocfs2: harden inode validators against forged metadata\", v2. This series adds three structural checks to OCFS2 dinode validation so malformed on-disk fields are rejected before ocfs2_populate_inode() copies them into the in-core inode. The checks cover: - i_mode values whose type bits do not name a canonical POSIX file type; - non-device dinodes whose id1.dev1.i_rdev field is non-zero; and - non-inline dinodes that claim non-zero i_size while i_clusters is zero, covering directories unconditionally and regular files on non-sparse volumes. The normal read path reports these through ocfs2_error(), matching the existing suballoc-slot, inline-data, chain-list, and refcount checks. The online filecheck path uses the same structural predicates but keeps its own reporting contract, returning OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(). This patch (of 3): ocfs2_validate_inode_block() currently accepts any non-zero i_mode value. ocfs2_populate_inode() then copies that mode verbatim into inode->i_mode and dispatches on i_mode & S_IFMT to the file/dir/symlink/special_file iops; an unrecognised type falls through to ocfs2_special_file_iops and init_special_inode(). Reject dinodes whose type bits do not name one of the seven canonical POSIX file types. Use fs_umode_to_ftype(), the same generic file-type conversion helper OCFS2 already uses for directory entries, so the accepted inode type set matches the kernel file-type vocabulary instead of open-coding a local switch. Apply the same structural check to the online filecheck read path. filecheck keeps its own error namespace, so it reports malformed i_mode through the filecheck logger and OCFS2_FILECHECK_ERR_INVALIDINO instead of calling ocfs2_error(), but it must not allow a malformed dinode to proceed into ocfs2_populate_inode().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72163", "url": "https://ubuntu.com/security/CVE-2026-72163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits [BUG] A direct write over unwritten extents can panic the kernel in ocfs2_assure_trans_credits() when the journal aborts during DIO completion. The crash is a general protection fault from a NULL pointer dereference. [CAUSE] ocfs2_dio_end_io_write() loops over a direct write's unwritten extents, marking each written under a single journal handle. If the journal aborts (for example after an I/O error) while the extent tree is being updated, the handle is left aborted with its transaction pointer cleared. The extent merge treats that failure as not critical and reports success, so the loop keeps using the handle. ocfs2_assure_trans_credits() reads the handle's remaining credits without first checking whether the handle is aborted, and that read dereferences the cleared transaction pointer. [FIX] A journal abort is recorded in the handle itself, so callers are expected to test the handle rather than rely on a returned error. Make ocfs2_assure_trans_credits() do that, as the other ocfs2 journal helpers already do, and return -EROFS when the handle is aborted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72164", "url": "https://ubuntu.com/security/CVE-2026-72164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: avoid moving extents to occupied clusters For non-auto OCFS2_IOC_MOVE_EXT operations, userspace supplies a physical me_goal. ocfs2_move_extent() initializes new_phys_cpos from that goal and expects ocfs2_probe_alloc_group() to replace it with a free run in the target block group. The probe currently leaves *phys_cpos unchanged if the scan reaches the end of the group without finding a free run. An occupied goal at the last bit can therefore survive the probe and be passed to __ocfs2_move_extent(), which copies file data into a cluster still owned by another inode before the bitmap is updated. When the probe does find a free run, it also subtracts move_len from the ending bit. The start of an N-bit run ending at i is i - N + 1, so the current calculation can report the bit immediately before the free run. Clear *phys_cpos before scanning and use the correct free-run start. Callers already treat a zero result as -ENOSPC, so failed probes no longer continue with an occupied caller-controlled goal.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72165", "url": "https://ubuntu.com/security/CVE-2026-72165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: fix condition in 'nand_select_target()' 'cs' here must be in range [0:nanddev_ntargets[.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72166", "url": "https://ubuntu.com/security/CVE-2026-72166", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix infinite loop in p9_client_rpc on fatal signal When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop: again: \terr = io_wait_event_killable(req->wq, ...) \t/* SIGKILL wakes the task, returns -ERESTARTSYS */ \tif (err == -ERESTARTSYS && c->status == Connected && \t\ttype == P9_TFLUSH) { \t\tsigpending = 1; \t\tclear_thread_flag(TIF_SIGPENDING); \t\tgoto again; \t} clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely. This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever: INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: context_switch kernel/sched/core.c:5344 [inline] __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline] __wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline] wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline] do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller. The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72167", "url": "https://ubuntu.com/security/CVE-2026-72167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72171", "url": "https://ubuntu.com/security/CVE-2026-72171", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: slram: remove failed entries from the device list register_device() links a new slram_mtdlist entry before allocating all of the state needed by the entry. If a later allocation, memremap(), or mtd_device_register() fails, the partially initialized entry remains on the global list. A later cleanup can then dereference or free invalid state from that failed entry. Unwind the partially initialized entry and clear the list tail on each failure path after the entry has been linked.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72181", "url": "https://ubuntu.com/security/CVE-2026-72181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mips: sched: Fix CPUMASK_OFFSTACK memory corruption This patch addresses a critical memory management flaw. When CONFIG_CPUMASK_OFFSTACK is enabled, cpumask_var_t is a pointer. Consequently, sizeof(new_mask) evaluates to the pointer size, causing copy_from_user() to clobber the mask pointer. Furthermore, the old logic performed copy_from_user() before allocating the mask. Fix this by allocating new_mask first. To handle variable-sized user masks correctly, use cpumask_size() to truncate overly large user masks or pad undersized masks with zeros before copying the data directly into the allocated buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72182", "url": "https://ubuntu.com/security/CVE-2026-72182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: supply: charger-manager: fix refcount leak in is_full_charged() In is_full_charged(), power_supply_get_by_name() is called to obtain a reference to the fuel_gauge power supply. If the voltage check (uV >= desc->fullbatt_uV) succeeds, the function returns true directly without releasing the reference, leaking the refcount. Fix this by setting a flag and jumping to the out label where power_supply_put() properly drops the reference.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72192", "url": "https://ubuntu.com/security/CVE-2026-72192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head indx_insert_into_root() promotes a full resident $INDEX_ROOT into $INDEX_ALLOCATION and copies all non-last resident root entries into a newly allocated INDEX_BUFFER via hdr_insert_head(). The source byte count 'to_move' is summed from the on-disk resident entry sizes and is independent of the destination buffer size, which comes from root->index_block_size (via indx->index_bits). A crafted NTFS image that keeps a valid, full resident root but shrinks root->index_block_size down to 512 after the root has been populated makes hdr_insert_head() memcpy attacker-controlled resident entry bytes past the end of the kmalloc(1u << indx->index_bits) allocation returned by indx_new(). For a 512-byte destination and a resident root whose non-last entries total 560 bytes, the memcpy overruns by 120 bytes and a following memmove extends the highest written offset to 136 bytes past the allocation. The overflow bytes are a direct copy of on-disk entries (via kmemdup), so they are fully attacker-controlled. The write is reachable from unprivileged open(O_CREAT) on a mounted crafted NTFS image: a single sufficiently long create in a directory whose resident root is already full forces root promotion and triggers the copy. This is a controlled out-of-bounds write of 120-136 bytes past a kmalloc(index_block_size) allocation, with attacker-controlled content. It is a bounded adjacent-heap corruption primitive; it is not an arbitrary-address write. Successful exploitation into a named victim object depends on the surrounding slab layout. Reject the copy at the sink. The destination's INDEX_HDR already reports hdr_total (the payload capacity of the new buffer) and hdr_used (the bytes already consumed by the terminal END entry installed by indx_new()); require that to_move fits in the remaining payload before calling hdr_insert_head(). On mismatch, fail with -EINVAL and mark the filesystem as having a detected on-disk inconsistency, which is the same behaviour as the surrounding validation in this function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72193", "url": "https://ubuntu.com/security/CVE-2026-72193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: cap RESTART_TABLE free-chain walker at rt->used A crafted NTFS3 disk image triggers an in-kernel infinite loop at mount time, hanging the mounting thread and firing the soft-lockup watchdog within ~22s on multi-CPU hosts (panic with kernel.softlockup_panic=1). The bug is reachable from desktop USB auto-mount on distributions where udisks2 routes the NTFS signature to the in-tree ntfs3 driver (Arch family and an increasing fraction of Fedora / openSUSE / RHEL deployments); CAP_SYS_ADMIN-class manual mount elsewhere. check_rstbl()'s second walker iterates the free-entry singly-linked list headed by rt->first_free with no upper bound on iteration count: for (off = ff; off;) { if (off == RESTART_ENTRY_ALLOCATED) return false; off = le32_to_cpu(*(__le32 *)Add2Ptr(rt, off)); if (off > ts - sizeof(__le32)) return false; } The existing guards cover three exits: end-of-list (off == 0), the in-use marker (off == RESTART_ENTRY_ALLOCATED), and out-of-bounds (off > ts - sizeof(__le32)). None of the three prevents an in-bounds cycle. A crafted on-disk RESTART_TABLE whose free chain contains a self-loop or A->B->A cycle whose offsets satisfy: - in range [sizeof(struct RESTART_TABLE), ts - sizeof(__le32)] - (off - sizeof(struct RESTART_TABLE)) % rsize == 0 passes all existing guards and spins the mount-time thread forever. Reproduced in UML by hand-forging a 2 MB NTFS3 image whose journal RESTART_TABLE first_free = 0x18 and whose entry at offset 0x18 stores 0x18 as its next pointer; mount of the forged image with the in-tree ntfs3 driver never returns. Bound the walker by rt->used. Each entry on a legitimate free chain is unique, and the total slot count is ne = le16_to_cpu (rt->used). A traversal that visits more than ne slots is by construction malformed; reject it as a corrupt RESTART_TABLE. After this patch, mount of the forged image returns with -EINVAL and a log_replay failure message, and mkntfs-produced legitimate images mount cleanly (verified in the same UML harness).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64532", "url": "https://ubuntu.com/security/CVE-2026-64532", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound NTFS_DE view.data_off in UpdateRecordData{Root,Allocation} In do_action()'s UpdateRecordDataRoot (fslog.c:3489) and UpdateRecordDataAllocation (fslog.c:3697) cases, the memmove destination is `Add2Ptr(e, le16_to_cpu(e->view.data_off))`, where e->view.data_off comes from an on-disk NTFS_DE inside an INDEX_ROOT or INDEX_BUFFER. Neither case validates view.data_off + dlen against e->size; the existing check_if_index_root / check_if_alloc_index helpers walk the entry chain and validate the entry's offset, but not its internal view fields. The neighbouring read sites (e.g., fs/ntfs3/index.c when iterating view entries) check view.data_off + view.data_size <= e->size. Apply the same bound at the two memmove sites. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe instrumentation: with view.data_off forced to 0xFFFC, the memmove writes 32 bytes past the end of the NTFS_DE. This is similar in shape to Pavitra Jha's 2026-05-02 patch \"fs/ntfs3: prevent oob in case UpdateRecordDataRoot\" (<20260502105008.21827-1-jhapavitra98@gmail.com>) which proposes calling ntfs3_bad_de_range(); that helper does not exist in mainline. This patch uses inline checks.", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72194", "url": "https://ubuntu.com/security/CVE-2026-72194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow indx_find_buffer() recursively descends the B+ tree index with no depth limit. A crafted NTFS image with circular index node references causes unbounded recursion, overflowing the kernel stack and panicking the system. This is reachable by mounting a malicious NTFS filesystem (e.g. from a USB drive via desktop automount) and deleting a file whose index entry triggers the rebalancing fallback path in indx_delete_entry(). Add a depth parameter and bail out with -EINVAL when it reaches the fnd->nodes array bound, matching the constraint already enforced by fnd_push() in indx_find(). The related function indx_find() was previously patched for a similar infinite-loop issue (commit 1732053c8a6b), but indx_find_buffer() was missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64533", "url": "https://ubuntu.com/security/CVE-2026-64533", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate lcns_follow in log_replay conversion log_replay() converts DIR_PAGE_ENTRY_32 records into DIR_PAGE_ENTRY records when replaying version 0 restart tables. During this conversion, the memmove() length is derived directly from the on-disk lcns_follow field: \tmemmove(&dp->vcn, &dp0->vcn_low, \t\t2 * sizeof(u64) + \t\t\t\tle32_to_cpu(dp->lcns_follow) * sizeof(u64)); check_rstbl() validates restart table structure, but does not constrain per-entry lcns_follow values relative to the entry size. A malformed filesystem image can provide an oversized lcns_follow value, causing the conversion memmove() to access memory beyond the bounds of the allocated restart table buffer. The same field is later used to bound iteration over page_lcns[], so validating lcns_follow during conversion also prevents downstream out-of-bounds access from the same malformed metadata. Compute the maximum valid lcns_follow from the already-validated restart table entry size and reject entries that exceed this bound. Reuse the existing t16/t32 scratch variables already declared in log_replay() to avoid introducing new declarations. [almaz.alexandrovich@paragon-software.com: fixed the conflicts]", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-72195", "url": "https://ubuntu.com/security/CVE-2026-72195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound attr_off in UpdateResidentValue against data_off In do_action()'s UpdateResidentValue case (fslog.c:3307), lrh->attr_off and lrh->redo_len come from the on-disk LRH. When they satisfy aoff + dlen < attr->res.data_off, the assignment \tattr->res.data_size = cpu_to_le32(aoff + dlen - data_off); underflows to ~4 GiB (e.g. 0xFFFFFFF9 when aoff=0x10, dlen=1, data_off=0x18). Subsequent code that reads attr->res.data_size to walk the resident attribute payload would then read up to 4 GiB past the 1024-byte MFT record allocation. The existing mi_enum_attr() defense in fs/ntfs3/record.c:287 catches the corrupted data_size on the next attribute walk and fails the mount, but only on the path that walks all attributes. A read site that picks an attribute by name and reads its data_size without re-validating is not covered. Validate aoff against data_off and asize at the source. Reproduced under UML+KASAN on mainline 8d90b09e6741 via pr_warn-only probe: with aoff=0x10 and data_off=0x18, the post-assignment data_size is 0xfffffff9 (mount then fails at -22 from mi_enum_attr). [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72197", "url": "https://ubuntu.com/security/CVE-2026-72197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: \tif (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || \t Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || \t used + esize > le32_to_cpu(hdr->total)) { \t\tgoto dirty_vol; \t} Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72215", "url": "https://ubuntu.com/security/CVE-2026-72215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable number of callback queues. has been printed. It seems that only the prom_printf() entry point is affected. Of all the other entry points wired only rex_slot_address() and rex_gettcinfo() are called from a kernel thread other than the initial one, specifically kernel_init(), and they are leaf functions that do no business with the stack, having worked with no issue ever since 64-bit support was added for the platform back in 2002. To address this issue then, arrange for the stack to be switched in the o32 wrapper as required for prom_printf() only, by supplying call_o32() with a pointer to a chunk of initdata space, which is placed in the CKSEG0 32-bit compatibility segment, observing that prom_printf() is only called from console output handler and therefore with the console lock held, implying no need for this code to be reentrant. Other firmware entry points may be called with interrupts enabled and no lock held, and may therefore require that call_o32() be reentrant. They trigger no issue at this point and \"if it ain't broke, don't fix it,\" so just leave them alone.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72218", "url": "https://ubuntu.com/security/CVE-2026-72218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure The cached-file path in nlm_lookup_file() reaches the found: label unconditionally, even when nlm_do_fopen() fails. At that label *result and file->f_count are updated before the error is returned. The wrappers nlm3svc_lookup_file() and nlm4svc_lookup_file() then bail out of their switch without copying *result back to their caller, so the proc handler's local nlm_file pointer remains NULL and the cleanup path skips nlm_release_file(). The f_count increment is never released, and nlm_traverse_files() can no longer reap the file because its refcount never returns to zero between requests. Short-circuit the cached path so neither *result nor f_count is touched when nlm_do_fopen() fails on a hashed nlm_file.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72219", "url": "https://ubuntu.com/security/CVE-2026-72219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lockd: Plug nlm_file leak when nlm_do_fopen() fails A client can repeatedly drive nlm_do_fopen() failures by presenting file handles that the underlying export rejects. After kzalloc_obj() succeeds in nlm_lookup_file(), the freshly allocated nlm_file is not yet inserted into nlm_files[]. The nlm_do_fopen() failure path jumps to out_unlock, which releases nlm_file_mutex and returns without freeing the allocation, so each failure leaks one nlm_file. Route the failure through out_free so kfree() runs before the function returns.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72223", "url": "https://ubuntu.com/security/CVE-2026-72223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arena sub-allocations on discover_arenas() error path Memory allocated by btt_freelist_init(), btt_rtt_init(), and btt_maplocks_init() is not freed on some discover_arenas() error paths. This leaks memory when arena discovery fails. Add the missing kfree() calls to release the allocations before returning an error. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72224", "url": "https://ubuntu.com/security/CVE-2026-72224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arenas on btt_init() error paths The arenas allocated by discover_arenas() or create_arenas() are not freed on some error paths in btt_init(). This leaks memory when BTT initialization fails. Call free_arenas() from the affected error paths to release the allocations. [ as: commit message and log edits ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72225", "url": "https://ubuntu.com/security/CVE-2026-72225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit() jbd2_journal_initialize_fast_commit() validates journal capacity by checking (journal->j_last - num_fc_blks < JBD2_MIN_JOURNAL_BLOCKS). Both j_last and num_fc_blks are unsigned, so when num_fc_blks exceeds j_last the subtraction wraps to a large value, bypassing the bounds check. The resulting underflow corrupts j_last, j_fc_first, and j_free, leading to journal abort. Fix by checking num_fc_blks against j_last before the subtraction, returning -EFSCORRUPTED.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72226", "url": "https://ubuntu.com/security/CVE-2026-72226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: prevent TVLV OOB check overflow A TT unicast TVLV contains the number of VLANs stored in it. This number is an u16 and gets multiplied by the size of the struct batadv_tvlv_tt_vlan_data (8 bytes). The size can therefore overflow the u16 used to store the tt_vlan_len. All additional safety checks to prevent out-of-bounds access of the TVLV buffer are invalid due to this overflow. Using size_t prevents this overflow and ensures that the safety checks compare against the actual buffer requirements.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72228", "url": "https://ubuntu.com/security/CVE-2026-72228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: fix primary_if leak on failed linearization If the skb has a frag_list, it must be linearized before it can be split using skb_split(). But when this step failed, it must not only free the skb but also take care of the reference to the already found primary_if.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72230", "url": "https://ubuntu.com/security/CVE-2026-72230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: frag: free unfragmentable packet The caller of batadv_frag_send_packet() assume that the skb provided to the function are always consumed. But the pre-check for an empty payload or the zero fragment size returned an error without any further actions. A failed pre-check must use the same error handling code as the rest of the function.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72231", "url": "https://ubuntu.com/security/CVE-2026-72231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is \"ret == false\". But the actual implementation is checking for \"ret == true\". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72233", "url": "https://ubuntu.com/security/CVE-2026-72233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: reacquire gw address after skb realloc The pskb_may_pull() called by batadv_bla_is_backbone_gw() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72234", "url": "https://ubuntu.com/security/CVE-2026-72234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: access unicast_ttvn skb->data only after skb realloc The pskb_may_pull() called by batadv_get_vid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free. This was done correctly for the ethernet header but missed for the unicast_packet pointer.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72238", "url": "https://ubuntu.com/security/CVE-2026-72238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/boot: Validate console=uart8250 baud rate to fix early boot hang When the baud rate is empty, 0, invalid, or overflows to 0 when stored as an int, the system will hang during early boot because of a division by zero in early_serial_init(). Fall back to DEFAULT_BAUD when the resulting baud rate is 0 to prevent an early system hang.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72240", "url": "https://ubuntu.com/security/CVE-2026-72240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix reference leak on failed device registration When platform_device_register() fails in sm501_register_device(), the embedded struct device in pdev has already been initialized by device_initialize(), but the failure path only reports the error and returns without dropping the device reference for the current platform device: sm501_register_device() -> platform_device_register(pdev) -> device_initialize(&pdev->dev) -> setup_pdev_dma_masks(pdev) -> platform_device_add(pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before returning the error. The issue was identified by a static analysis tool I developed and confirmed by manual review.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72241", "url": "https://ubuntu.com/security/CVE-2026-72241", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: leds: uleds: Fix potential buffer overread The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72245", "url": "https://ubuntu.com/security/CVE-2026-72245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error path After device_initialize(), the embedded struct device in struct host1x_device should be released through the device core with put_device(). In host1x_device_add(), if host1x_device_parse_dt() fails, the current error path frees the object directly with kfree(device). That bypasses the normal device lifetime handling and leaks the reference held on the embedded struct device. The issue was identified by a static analysis tool I developed and confirmed by manual review. Fix this by using put_device() in the host1x_device_parse_dt() failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-64554", "url": "https://ubuntu.com/security/CVE-2026-64554", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment() br_ip6_fragment() gets prevhdr, a pointer into the skb head, from ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb skb_checksum_help() reallocates the head via pskb_expand_head(), leaving prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a use-after-free write. Save prevhdr's offset before skb_checksum_help() and recompute it after, like commit ef0efcd3bd3f (\"ipv6: Fix dangling pointer when ipv6 fragment\"). BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857) Write of size 1 at addr ffff888013ff5016 by task exploit/141 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip6_frag_next (net/ipv6/ip6_output.c:857) br_ip6_fragment (net/ipv6/netfilter.c:212) nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407) nf_hook_slow (net/netfilter/core.c:619) br_forward_finish (net/bridge/br_forward.c:66) __br_forward (net/bridge/br_forward.c:115) maybe_deliver (net/bridge/br_forward.c:191) br_flood (net/bridge/br_forward.c:245) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:442) ... packet_sendmsg (net/packet/af_packet.c:3114) ... do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72247", "url": "https://ubuntu.com/security/CVE-2026-72247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: fix zone comparison in tuple dedup The \"already exists\" dedup logic in __nf_conncount_add() decides whether a connection has already been counted and can be skipped instead of incrementing the connlimit count. It compares the conntrack zone of a list entry with the zone of the connection being added using nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or zone->dir as the direction argument. Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0 and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask: NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction shifts the meaning of every non-zero value. An ORIG-only zone passes 1 and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and test bits beyond the valid direction range. In those cases nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using the real zone id, so different zones can be treated as equal and dedup collapses to tuple equality alone. nf_conncount stores and compares the original-direction tuple for a connection. If an skb already has an attached conntrack entry, get_ct_or_tuple_from_skb() explicitly copies ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's ctinfo. Therefore the zone comparison in the tuple dedup path must use IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a zone id applies, not which direction this conncount tuple represents. Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly. Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional zone contains the ORIG bit, so it naturally returns the real zone id; reply-only zones continue to fall back for original-direction tuple comparisons.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72250", "url": "https://ubuntu.com/security/CVE-2026-72250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6 defrag nf_ct_frag6_reasm() slides the packet head forward to drop the IPv6 fragment header and then unconditionally advances skb->mac_header: \tskb->mac_header += sizeof(struct frag_hdr); On the NF_INET_LOCAL_OUT defrag path the skb has no link-layer header yet, so skb->mac_header is still the \"not set\" sentinel (u16)~0U. Adding sizeof(struct frag_hdr) wraps it to a small value (0xffff + 8 == 7), after which skb_mac_header_was_set() wrongly reports a MAC header is present and skb_mac_header() points into the headroom. The reassembler has done this unconditional add since it was introduced; it was harmless while mac_header was a bare pointer, but wrong once mac_header became a u16 offset whose unset state is the ~0U sentinel tested by skb_mac_header_was_set(). The sibling net/ipv6/reassembly.c does the same relocation and does guard the adjustment; mirror the guard here.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72251", "url": "https://ubuntu.com/security/CVE-2026-72251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_nat_sip: reload possible stale data pointer quoting sashiko: ------------------------------------------------------------------------ [..] noticed a potential memory bug and header corruption involving the SIP NAT helper. In net/netfilter/nf_nat_sip.c:nf_nat_sip(): \tif (skb_ensure_writable(skb, skb->len)) { \t\tnf_ct_helper_log(skb, ct, \"cannot mangle packet\"); \t\treturn NF_DROP; \t} \tuh = (void *)skb->data + protoff; \tuh->dest = ct_sip_info->forced_dport; \tif (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, \t\t\t\t 0, 0, NULL, 0)) { If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the old data buffer is freed. However, nf_nat_sip() fails to update *dptr to point to the new buffer. It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP packet, which would overwrite the sequence number with a checksum update. ------------------------------------------------------------------------ nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen. But clones are possible, so rebuild dptr. Disable nf_nat_mangle_udp_packet() branch for TCP streams. It doesn't look like this can ever happen, else we should have received bug reports about this, so just check the conntrack is UDP and drop otherwise. The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages, so I don't think this is ever expected to be true for a TCP stream.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72256", "url": "https://ubuntu.com/security/CVE-2026-72256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_cluster: reject template conntracks in hash match xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72264", "url": "https://ubuntu.com/security/CVE-2026-72264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tridentfb: fix potential memory leak in trident_pci_probe() In trident_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72265", "url": "https://ubuntu.com/security/CVE-2026-72265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: nvidia: fix potential memory leak in nvidiafb_probe() In nvidiafb_probe(), the memory allocated for modelist in nvidia_set_fbinfo() is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72267", "url": "https://ubuntu.com/security/CVE-2026-72267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: carminefb: fix potential memory leak in alloc_carmine_fb() The memory allocated for modelist in fb_videomode_to_modelist() is not freed in the subsequent error path. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72268", "url": "https://ubuntu.com/security/CVE-2026-72268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe() In tdfxfb_probe(), the memory allocated for modelist using fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not freed in the subsequent error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72269", "url": "https://ubuntu.com/security/CVE-2026-72269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: uvesafb: fix potential memory leak in uvesafb_probe() Due to an incorrect goto label, memory allocated for modedb and modelist in uvesafb_vbe_init() is not freed in some error paths. Fix this by updating the goto label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72270", "url": "https://ubuntu.com/security/CVE-2026-72270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: s3fb: fix potential memory leak in s3_pci_probe() In s3_pci_probe(), the memory allocated for modelist using fb_videomode_to_modelist() is not freed in subsequent error paths. Fix that by calling fb_destroy_modelist()", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72271", "url": "https://ubuntu.com/security/CVE-2026-72271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: i740fb: fix potential memory leak in i740fb_probe() In i740fb_probe(), the memory allocated in fb_videomode_to_modelist() for modelist is not freed in the error paths. Fix that by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72272", "url": "https://ubuntu.com/security/CVE-2026-72272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: radeon: fix potential memory leak in radeonfb_pci_register() The function radeonfb_pci_register() allocates memory for modelist (by calling radeon_check_modes() which calls fb_add_videomode()). The memory is appended to info->modelist, but is not freed in subsequent error paths. Fix this by calling fb_destroy_modelist().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72274", "url": "https://ubuntu.com/security/CVE-2026-72274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: hecubafb: fix potential memory leak in hecubafb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72275", "url": "https://ubuntu.com/security/CVE-2026-72275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72276", "url": "https://ubuntu.com/security/CVE-2026-72276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: metronomefb: fix potential memory leak in metronomefb_probe() The memory allocated for pagerefs in fb_deferred_io_init() is not freed on the error path. Fix it by calling fb_deferred_io_cleanup().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72289", "url": "https://ubuntu.com/security/CVE-2026-72289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic: Check the interrupt is still ours before migrating it vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating an interrupt to another vCPU. After reacquiring the locks it only checks that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq)) before moving the interrupt, which assumes that an interrupt whose affinity is preserved is still queued on this vCPU's ap_list. That assumption no longer holds if the interrupt is taken off the ap_list while the locks are dropped. vgic_flush_pending_lpis() removes the interrupt from the list and sets irq->vcpu to NULL, but leaves enabled/pending/target_vcpu untouched. As the interrupt is still enabled and pending, vgic_target_oracle() returns the same target_vcpu, so the affinity check passes and list_del() is run a second time on an entry that has already been removed. Also check that the interrupt is still assigned to this vCPU (irq->vcpu == vcpu) before moving it.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72296", "url": "https://ubuntu.com/security/CVE-2026-72296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ife: require ETH_HLEN to be pullable in ife_decode() ife decode may return after making only the outer IFE header and metadata pullable. The caller then passes the decapsulated packet to eth_type_trans(), which expects the inner Ethernet header to be accessible from the linear data area. With a malformed IFE frame, the inner Ethernet header may still be shorter than ETH_HLEN in the linear area, which can lead to a crash in the original code. Fix this by extending the pull check in ife_decode() so that the inner Ethernet header is also guaranteed to be pullable before returning.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72297", "url": "https://ubuntu.com/security/CVE-2026-72297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: atm: reject out-of-range traffic classes in QoS validation Reject ATM traffic classes above ATM_ANYCLASS in check_tp(). SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so accepting larger values leaves invalid traffic_class values in vcc->qos. That bad state later reaches pvc_info(), which indexes class_name[] with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause an out-of-bounds read when /proc/net/atm/pvc is read. Tighten the existing QoS validation so invalid traffic_class values are rejected at the point where user supplied QoS is accepted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72298", "url": "https://ubuntu.com/security/CVE-2026-72298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post() qrtr_endpoint_post() validates an incoming packet with \tif (!size || len != ALIGN(size, 4) + hdrlen) \t\tgoto err; where size comes from the wire. On 32-bit, size_t is 32 bits and ALIGN(size, 4) wraps to 0 for size >= 0xfffffffd, so the check passes and skb_put_data(skb, data + hdrlen, size) writes past the hdrlen-sized skb and oopses the kernel. 64-bit is unaffected. This is the 32-bit residual of ad9d24c9429e2 (\"net: qrtr: fix OOB Read in qrtr_endpoint_post\"), which fixed only the 64-bit case. Reject any size that cannot fit the buffer before the ALIGN.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72306", "url": "https://ubuntu.com/security/CVE-2026-72306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter: vduse_dev_read_iter(): lock(msg_lock); dequeue_msg(send_list); unlock(msg_lock); vduse_dev_msg_sync(): wait_timeout() finish lock(msg_lock); check msg->complete is false list_del(msg); <- double list_del() crash! To fix this case, we shall ensure vduse_msg is on send_list or recv_list outside the msg_lock critical section.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72307", "url": "https://ubuntu.com/security/CVE-2026-72307", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace() When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs, the error rollback loop does not correctly revert the preceding replacements. The loop decrements the index but fails to update the vr pointer, which still points to the VR that caused the failure. As a result, the condition and the rollback call always operate on the same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple times on it while never rolling back the earlier VRs. Those VRs continue to hold a reference to new_tree acquired via mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree. Fix by reinitializing vr inside the error loop with the updated index: \tvr = &mlxsw_sp->router->vrs[i]; so that the loop correctly iterates over all VRs that were actually replaced.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72310", "url": "https://ubuntu.com/security/CVE-2026-72310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check smb2_ioctl_query_info() validates the PASSTHRU_FSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.input_buffer_length directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copy_to_user() then reads from io_rsp + OutputOffset, outside the response buffer. Use size_add() for the offset plus length check so overflow is treated as out of bounds.", "cve_priority": "negligible", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72314", "url": "https://ubuntu.com/security/CVE-2026-72314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: regulator_lock_two() should test for EDEADLK not EDEADLOCK Compare against -EDEADLK, which is what ww_mutex_lock() actually returns and what every other deadlock check in this file already uses. Function regulator_lock_two() acquires two regulators via regulator_lock_nested() -> ww_mutex_lock(). On contention, ww_mutex_lock() returns -EDEADLK, which is the caller's signal to drop the lock it holds and retry the acquisition in the canonical order. However, regulator_lock_two() tests the return value against -EDEADLOCK rather than -EDEADLK. On most architectures, EDEADLK and EDEADLOCK are the same value, so the comparison happens to be correct and the bug is invisible. But on MIPS, SPARC, and PowerPC, those two errors have different values. The test is wrong: a genuine -EDEADLK backoff no longer matches -EDEADLOCK, so instead of unlocking and retrying, the code falls into WARN_ON(ret) and returns with only one of the two regulators locked. In practice, this is a bug only on MIPS, because the regulator core is not built or used on the other two platforms. In general, EDEADLK is preferred over EDEADLOCK for new code.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72316", "url": "https://ubuntu.com/security/CVE-2026-72316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm era: fix NULL pointer dereference in metadata_open() metadata_open() returns NULL when kzalloc_obj() fails, but the caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed. Fix this by returning ERR_PTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the same pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72319", "url": "https://ubuntu.com/security/CVE-2026-72319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: ensure inner headers in ICMP errors are in headroom Sashiko points out that after stripping the outer headers with pskb_pull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4_update_pmtu(), icmp_send() and IP_VS_DBG(). Also, add more checks for the length of the inner headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72322", "url": "https://ubuntu.com/security/CVE-2026-72322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a \"refcount_t: addition on 0\" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device is already being destroyed. If the refcount is 0, we do not schedule the work.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72326", "url": "https://ubuntu.com/security/CVE-2026-72326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cake: reject overhead values that underflow length CAKE accepts signed overhead values and stores them in an s16, but the adjusted packet length calculation uses unsigned arithmetic. A negative effective length can therefore wrap to a large value. Such configurations make rate accounting depend on integer wraparound rather than on the packet size userspace intended to model. A static netlink lower bound is not enough because packets reaching CAKE can be smaller than any reasonable manual-overhead allowance. Fold the signed overhead adjustment into the existing datapath MPU clamp so negative adjusted lengths are clamped before link-layer framing adjustments.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64549", "url": "https://ubuntu.com/security/CVE-2026-64549", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup() bpa10x_setup() sends the vendor command 0xfc0e and passes the response to bt_dev_info() and hci_set_fw_info() as a \"%s\" string starting at skb->data + 1, without checking the length: \tbt_dev_info(hdev, \"%s\", (char *)(skb->data + 1)); \thci_set_fw_info(hdev, \"%s\", skb->data + 1); A device that returns a one-byte response (status only) leaves skb->data + 1 past the end of the data, and the %s walk reads adjacent slab memory until it meets a NUL. The same happens when the payload is not NUL-terminated within skb->len. The out-of-bounds bytes end up in the kernel log and the firmware-info debugfs file. Print the revision string with a bounded \"%.*s\" limited to skb->len - 1 instead. This keeps the string readable for well-behaved devices while never reading past the received data, and does not fail setup, so a device returning a short or unterminated response keeps working.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64541", "url": "https://ubuntu.com/security/CVE-2026-64541", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket smc_cdc_rx_handler() looks up the connection by token under the link group's conns_lock, drops the lock, and then dereferences conn and the smc_sock derived from it, ending in sock_hold(&smc->sk) inside smc_cdc_msg_recv(). No reference is held across the lock release. The only reference pinning the socket while the connection is discoverable in the link group is taken in smc_lgr_register_conn() (sock_hold) and dropped in __smc_lgr_unregister_conn() (sock_put), both under conns_lock. Once the handler drops conns_lock, a concurrent close() -> smc_release() -> smc_conn_free() -> smc_lgr_unregister_conn() can drop that reference and free the smc_sock, so the handler's later sock_hold() runs on freed memory: WARNING: lib/refcount.c:25 at refcount_warn_saturate Workqueue: rxe_wq do_work refcount_warn_saturate (lib/refcount.c:25) smc_cdc_msg_recv (net/smc/smc_cdc.c:430) smc_cdc_rx_handler (net/smc/smc_cdc.c:502) smc_wr_rx_tasklet_fn (net/smc/smc_wr.c:445) tasklet_action_common (kernel/softirq.c:938) handle_softirqs (kernel/softirq.c:622) Kernel panic - not syncing: panic_on_warn set Only SMC-R is affected. The SMC-D receive tasklet is stopped by tasklet_kill(&conn->rx_tsklet) in smc_conn_free() before the connection is unregistered, so it cannot run concurrently with the free. Take the socket reference while still holding conns_lock, so the registration reference can no longer be the last one, and drop it once the handler is done.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-64550", "url": "https://ubuntu.com/security/CVE-2026-64550", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: validate MAP frame length before ingress parsing When ingress deaggregation is disabled, rmnet_map_ingress_handler() passes the skb straight to __rmnet_map_ingress_handler(), skipping the length validation that rmnet_map_deaggregate() performs on the aggregated path. The parser then dereferences the MAP header and csum header/trailer based on the on-wire pkt_len without checking skb->len, so a short frame is read out of bounds: BUG: KASAN: slab-out-of-bounds in rmnet_map_checksum_downlink_packet Read of size 1 at addr ffff88801118ed00 by task exploit/147 Call Trace: ... rmnet_map_checksum_downlink_packet (drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:413) __rmnet_map_ingress_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:96) rmnet_rx_handler (drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:129) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6089) netif_receive_skb (net/core/dev.c:6460) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2001) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) do_syscall_64 (arch/x86/entry/syscall_64.c:94) ... Factor that validation out of rmnet_map_deaggregate() into rmnet_map_validate_packet_len() and run it on the no-aggregation path too. The MAP header is bounds-checked first, since this path can receive a frame shorter than the header.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72339", "url": "https://ubuntu.com/security/CVE-2026-72339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: qede: fix off-by-one in BD ring consumption on build_skb failure qede_rx_build_skb() and qede_tpa_rx_build_skb() do not check for a NULL return from qede_build_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption. Commit 4e910dbe3650 (\"qede: confirm skb is allocated before using\") added a NULL check inside qede_build_skb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable. Fix this by adding NULL checks for the return value of qede_build_skb() in both qede_rx_build_skb() and qede_tpa_rx_build_skb(), returning NULL immediately before any BD ring manipulation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72347", "url": "https://ubuntu.com/security/CVE-2026-72347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_connmark: reject invalid shift parameters Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmark_tg_shift(). A shift_bits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shift_dir values are also accepted and silently fall back to the left-shift path. Reject invalid revision-2 shift parameters in connmark_tg_check() so malformed rules fail at installation time, before they can reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72348", "url": "https://ubuntu.com/security/CVE-2026-72348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop The ah, hbh and rt matches check that the fixed extension header is present, then use the header length field to derive the advertised extension header length for matching. For the ah match, add the missing advertised-length check. For hbh and rt, update the existing advertised-length checks. In all three cases, set hotdrop to true before returning false when the advertised extension header length exceeds the available skb data. Returning false treats the packet as a rule mismatch. Set hotdrop to true and drop malformed packets so they cannot bypass rules intended to drop packets with these IPv6 extension headers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72349", "url": "https://ubuntu.com/security/CVE-2026-72349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt() On links faster than ~34 Gbps, where byte rate may exceed 2^32-1 (~ 4.3 GBps), the comparison result becomes incorrect because the truncated value no longer reflects the actual estimator rate. Fix by changing the local variables to u64.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72350", "url": "https://ubuntu.com/security/CVE-2026-72350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_u32: reject invalid shift counts u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation. Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72351", "url": "https://ubuntu.com/security/CVE-2026-72351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64547", "url": "https://ubuntu.com/security/CVE-2026-64547", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: net1080: validate packet_len before pad-byte access in rx_fixup For an even packet_len, net1080_rx_fixup() reads the pad byte at skb->data[packet_len] before the skb->len != packet_len check further down, and packet_len is only bounded against NC_MAX_PACKET. A malicious NetChip 1080 device can send a short frame advertising a large even packet_len (e.g. 0x4000), so the pad-byte read lands past the end of the skb: BUG: KASAN: slab-out-of-bounds in net1080_rx_fixup Read of size 1 at addr ffff8880106c83c6 by task ksoftirqd/0/14 ... net1080_rx_fixup (drivers/net/usb/net1080.c:384) usbnet_bh (drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3708) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) ... Reject the frame when packet_len >= skb->len before reading.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72371", "url": "https://ubuntu.com/security/CVE-2026-72371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the volume AFS_VOLUME_RM_TREE is set on Fix afs_insert_volume_into_cell() to set AFS_VOLUME_RM_TREE on the volume replaced, not the new volume, as it's now removed from the cell's volume tree. This will cause the old volume to be removed from the tree twice and the new volume never to be removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72374", "url": "https://ubuntu.com/security/CVE-2026-72374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix callback service message parsers to pass through -EAGAIN The AFS filesystem client uses an rxrpc server to listen for callback notifications. Each callback call type handler has a delivery function that parses the incoming request stream, and this should return -EAGAIN the last packet hasn't yet been seen, but all currently queued received data is consumed. afs_extract_data() does this, but the -EAGAIN return is switched to 0 inadvertantly Fix callback service message parsers to pass through -EAGAIN", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72378", "url": "https://ubuntu.com/security/CVE-2026-72378", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix error code in afs_extract_vl_addrs() The error codes on these paths are only set on the first iteration through the loop. Set the correct error code on every iteration.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72389", "url": "https://ubuntu.com/security/CVE-2026-72389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: stp: Fix a potential use-after-free when deleting a bridge The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them. This check is missing from br_topology_change_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted. Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted. [1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timer_list hint: br_topology_change_timer_expired (net/bridge/br_stp_timer.c:120) WARNING: lib/debugobjects.c:629 at debug_print_object+0x1bc/0x450, CPU#9: ip/359", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64540", "url": "https://ubuntu.com/security/CVE-2026-64540", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup() genelink_rx_fixup() splits an aggregated RX frame into its individual packets, using a per-packet length taken from device-supplied data. That length is only bounded by GL_MAX_PACKET_LEN (1514); it is never compared against how many bytes were actually received. A malicious GeneLink (GL620A) device can therefore send a short URB whose header claims packet_count > 1 and a first packet of up to 1514 bytes. \tskb_put_data(gl_skb, packet->packet_data, size); then copies past the end of the receive buffer and hands the adjacent slab contents up the network stack, an out-of-bounds read that leaks kernel heap. No privilege is required: the path runs in the usbnet RX softirq as soon as the interface is up. BUG: KASAN: slab-out-of-bounds in genelink_rx_fixup (drivers/net/usb/gl620a.c:112) Read of size 1514 at addr ffff888011309708 by task ksoftirqd/0/14 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) genelink_rx_fixup (include/linux/skbuff.h:2814 drivers/net/usb/gl620a.c:112) usbnet_bh (drivers/net/usb/usbnet.c:572 drivers/net/usb/usbnet.c:1589) process_one_work (kernel/workqueue.c:3322) bh_worker (kernel/workqueue.c:3405) tasklet_action (kernel/softirq.c:965) handle_softirqs (kernel/softirq.c:622) run_ksoftirqd (kernel/softirq.c:1076) ... skb_pull() already verifies that the requested length fits the buffer and returns NULL otherwise. Move it ahead of the copy and check its result, so a packet that overruns the received data is rejected before it is read. Well-formed frames, whose packets are fully present, are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72392", "url": "https://ubuntu.com/security/CVE-2026-72392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump inet6_dump_fib() saves its progress in cb->args[1] as a positional index within the current hash chain. Between batches, a concurrent fib6_new_table() can insert a new table at the chain head, shifting all existing entries. The saved index then lands on a different table, causing fib6_dump_table() to set w->root to the wrong table while w->node still points into the previous one. fib6_walk_continue() dereferences w->node->parent (NULL) and panics: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:fib6_walk_continue+0x6e/0x170 Call Trace: fib6_dump_table.isra.0+0xc5/0x240 inet6_dump_fib+0xf6/0x420 rtnl_dumpit+0x30/0xa0 netlink_dump+0x15b/0x460 netlink_recvmsg+0x1d6/0x2a0 ____sys_recvmsg+0x17a/0x190 Fix by storing tb->tb6_id in cb->args[1] instead of a positional index. On resume, skip entries until the id matches; a concurrent head-insert can never match the saved id, so the walker always resumes on the correct table.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72396", "url": "https://ubuntu.com/security/CVE-2026-72396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: adm1275: Prevent reading uninitialized stack While adding support for the ROHM BD127X0 hot-swap controllers, sashiko reported an error in device-name comparison, which can lead to reading uninitialized stack memory. Quoting Sashiko: This is a pre-existing issue, but I noticed that just before this block in adm1275_probe(), there might be an out-of-bounds stack read: ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, block_buffer); if (ret < 0) { ... } for (mid = adm1275_id; mid->name[0]; mid++) { if (!strncasecmp(mid->name, block_buffer, strlen(mid->name))) break; } Since i2c_smbus_read_block_data() reads up to 32 bytes into the uninitialized stack array block_buffer without appending a null terminator, strncasecmp() could read past the valid bytes returned in ret. For example, if the device returns a shorter string like \"adm12\", checking it against \"adm1275\" up to the length of \"adm1275\" will continue reading into uninitialized stack bounds. Prevent reading uninitialized memory by zeroing the stack array.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72400", "url": "https://ubuntu.com/security/CVE-2026-72400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: seg6: validate SRH length before reading fixed fields seg6_validate_srh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6_sr_hdr fields. The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the length to seg6_validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer. Reject lengths shorter than the fixed SRH at the top of seg6_validate_srh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72406", "url": "https://ubuntu.com/security/CVE-2026-72406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sungem: fix probe error cleanup gem_init_one() calls gem_remove_one() when register_netdev() fails. gem_remove_one() unregisters and frees resources owned by the net_device, including the DMA block, MMIO mapping, PCI regions, and the net_device itself. gem_init_one() then falls through to its own cleanup labels and frees the same resources again. Keep the register_netdev() error path in gem_init_one(): clear drvdata so PM/remove paths do not see a half-registered device, remove the NAPI instance added during probe, and let the existing cleanup labels release the resources once. The issue was found by a local static-analysis checker for probe error paths. The reported path was manually inspected before sending this fix. Compile-tested with CONFIG_SUNGEM=y. Runtime testing was not performed because no sungem hardware is available.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72409", "url": "https://ubuntu.com/security/CVE-2026-72409", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvneta: re-enable percpu interrupt on resume On Marvell MPIC platforms (Armada 370/XP/38x), mvneta uses a percpu IRQ disable/enable scheme for NAPI: the ISR (mvneta_percpu_isr) calls disable_percpu_irq() to mask the MPIC per-CPU interrupt and schedules NAPI poll, which calls enable_percpu_irq() on completion to unmask. If suspend occurs while NAPI poll is pending (between disable_percpu_irq in the ISR and enable_percpu_irq in poll completion), the interrupt is never re-enabled: 1. mvneta_percpu_isr: disable_percpu_irq() + napi_schedule() => MPIC masked, percpu_enabled cpumask bit cleared 2. NAPI poll does not complete before suspend proceeds (on PREEMPT_RT this is highly likely since softirqs run in ksoftirqd which gets frozen; on non-RT it can happen when softirq processing is deferred to ksoftirqd) 3. mvneta_stop_dev => napi_disable(): cancels the pending poll without executing the completion path 4. suspend_device_irqs => IRQCHIP_MASK_ON_SUSPEND: masks MPIC (already masked, but records IRQS_SUSPENDED) 5. Resume: mpic_resume checks irq_percpu_is_enabled() => false (bit was cleared in step 1) => skips unmask 6. mvneta_start_dev only restores device-level INTR_NEW_MASK, does not touch the MPIC per-CPU mask Result: MPIC per-CPU interrupt stays masked permanently. The NIC generates interrupts (INTR_NEW_CAUSE != 0) but the CPU never receives them, causing complete loss of network connectivity. Fix by calling on_each_cpu(mvneta_percpu_enable) in the resume path to unconditionally unmask the MPIC per-CPU interrupt regardless of pre-suspend state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64530", "url": "https://ubuntu.com/security/CVE-2026-64530", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.", "cve_priority": "medium", "cve_public_date": "2026-07-26 07:16:00 UTC" }, { "cve": "CVE-2026-72414", "url": "https://ubuntu.com/security/CVE-2026-72414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: round up PTP perout pin duration pin_duration is converted from the user-provided period to SJA1105 clock ticks and is later passed as the cycle_time argument to future_base_time(). Very small period values may become zero after the conversion, which can lead to a division by zero in future_base_time(). Round zero pin_duration up to 1 tick so that the smallest unsupported periods use the minimum non-zero hardware duration instead of passing zero to future_base_time().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64545", "url": "https://ubuntu.com/security/CVE-2026-64545", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net, bpf: check master for NULL in xdp_master_redirect() xdp_master_redirect() dereferences the result of netdev_master_upper_dev_get_rcu() without a NULL check, but that helper returns NULL when the receiving device has no upper-master adjacency. The reach guard only checks netif_is_bond_slave(). On bond slave release bond_upper_dev_unlink() drops the upper-master adjacency before clearing IFF_SLAVE, so an XDP_TX reaching xdp_master_redirect() in that window still passes netif_is_bond_slave() while master is already NULL, and faults on master->flags at offset 0xb0: BUG: kernel NULL pointer dereference, address: 00000000000000b0 RIP: 0010:xdp_master_redirect (net/core/filter.c:4432) Call Trace: xdp_master_redirect (net/core/filter.c:4432) bpf_prog_run_generic_xdp (include/net/xdp.h:700) do_xdp_generic (net/core/dev.c:5608) __netif_receive_skb_one_core (net/core/dev.c:6204) process_backlog (net/core/dev.c:6319) __napi_poll (net/core/dev.c:7729) net_rx_action (net/core/dev.c:7792) handle_softirqs (kernel/softirq.c:622) __dev_queue_xmit (include/linux/bottom_half.h:33) packet_sendmsg (net/packet/af_packet.c:3082) __sys_sendto (net/socket.c:2252) Kernel panic - not syncing: Fatal exception in interrupt The missing check dates back to the original code; commit 1921f91298d1 (\"net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master\") later added the master->flags read where the fault now lands but kept the unconditional deref. Check master for NULL before use; a NULL master is treated the same as one that is not up.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72418", "url": "https://ubuntu.com/security/CVE-2026-72418", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: prevent connlimit drops for early confirmed ct Commit 69894e5b4c5e (\"netfilter: nft_connlimit: update the count if add was skipped\") introduced a regression where packets for valid connections are dropped when using connlimit for soft-limiting scenarios. The issue occurs when a new connection reuses a socket currently in the TIME_WAIT state. In this scenario, the connection tracking entry is evaluated as already confirmed. Previously, __nf_conncount_add() assumed that if a connection was confirmed and did not originate from the loopback interface, it should skip the addition and return -EEXIST. Skipping the addition triggers a garbage collection run that cleans up the TIME_WAIT connection. Consequently, the active connection count drops to 0, which xt_connlimit mishandles, leading to the false rejection of the perfectly valid new connection. Fix this by replacing the interface check with protocol-agnostic state checks. We now skip the tree insertion and preserve the lockless garbage collection optimization only if the connection is IPS_ASSURED. This allows early-confirmed setup packets (such as reused TIME_WAIT sockets or locally generated SYN-ACKs) to be properly evaluated and counted without falsely dropping. The goto check_connections path is maintained to ensure these setup packets are deduplicated correctly. This has been tested with slowhttptest and HTTP server configured locally to ensure we are not breaking soft-limiting scenarios for local or external connections. In addition, it was tested with a OVS zone limit too.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72421", "url": "https://ubuntu.com/security/CVE-2026-72421", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: Don't ignore error route in local/main tables. When CONFIG_IP_MULTIPLE_TABLES is enabled but no rule is added, fib_lookup() performs route lookup directly on two tables. Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table: # unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache Once a random rule is added, the error route is respected: # ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host Let's fix the inconsistent behaviour.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64538", "url": "https://ubuntu.com/security/CVE-2026-64538", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix null-ptr-deref in fib6_nh_mtu_change(). fib6_nh_mtu_change() re-fetches idev via __in6_dev_get(arg->dev) and dereferences idev->cnf.mtu6 without a NULL check. addrconf_ifdown() clears dev->ip6_ptr with RCU_INIT_POINTER() after rt6_disable_ip() has released tb6_lock, so the RA-driven MTU walk can observe a NULL idev and oops. The caller rt6_mtu_change_route() guards its own __in6_dev_get(), but this re-fetch is unguarded; nexthop-backed routes survive addrconf_ifdown()'s flush, so the walk still reaches it after ip6_ptr is nulled. Return 0 when idev is NULL, matching rt6_mtu_change_route() and the fib6_mtu() fix in commit 5ad509c1fdad (\"ipv6: Fix null-ptr-deref in fib6_mtu().\"). Oops: general protection fault, ... KASAN: null-ptr-deref in range [0x00000000000002a8-0x00000000000002af] RIP: 0010:fib6_nh_mtu_change+0x203/0x990 rt6_mtu_change_route+0x141/0x1d0 __fib6_clean_all+0xd0/0x160 rt6_mtu_change+0xb4/0x100 ndisc_router_discovery+0x24b5/0x2cb0 icmpv6_rcv+0x12e9/0x1710 ipv6_rcv+0x39b/0x410", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72422", "url": "https://ubuntu.com/security/CVE-2026-72422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2 NEGOTIATE conn->preauth_info is shared connection state (struct preauth_integrity_info, kmalloc-96) that is allocated and freed by the SMB2 NEGOTIATE handler and read by the response send path. smb2_handle_negotiate() allocates conn->preauth_info, and on a deassemble_neg_contexts() failure kfrees it and sets it to NULL. Both the allocation and the free/NULL happen under ksmbd_conn_lock(conn) (the connection srv_mutex), which is held across the whole handler body. The response send path smb3_preauth_hash_rsp(), called from the send: block of __handle_ksmbd_work(), reads conn->preauth_info and dereferences conn->preauth_info->Preauth_HashValue (via ksmbd_gen_preauth_integrity_hash()) without taking conn_lock. When a client drives two SMB2 NEGOTIATE requests on the same connection, one worker can free conn->preauth_info on the failing-negotiate path while a concurrent send-path worker is reading it, producing a slab use-after-free read (KASAN-confirmed). The send-path read tested conn->preauth_info for NULL but raced with the free that occurs between the NULL check and the dereference, so the NULL guard alone does not close the window. Serialize the NEGOTIATE-branch read in smb3_preauth_hash_rsp() under ksmbd_conn_lock(conn) and re-check conn->preauth_info inside the lock. Because the negotiate handler holds conn_lock across its kfree + NULL assignment, a reader that also takes conn_lock either runs fully before the allocation or fully after the NULL store, and can never observe the freed-but-not-yet-NULLed pointer. ksmbd_gen_preauth_integrity_hash() takes no locks itself (it only computes a SHA-512 over the buffer), so no lock-ordering inversion is introduced, and conn_lock is a sleepable mutex which is safe on this send path (it already performs network I/O).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64546", "url": "https://ubuntu.com/security/CVE-2026-64546", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix OOB read in drm_parse_tiled_block() drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read. Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does. BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72428", "url": "https://ubuntu.com/security/CVE-2026-72428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack slot index in nospec checks check_stack_write_fixed_off() computes the byte slot for a fixed-offset stack write as -off - 1, and records each written byte in slot_type[] with (slot - i) % BPF_REG_SIZE. The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a 4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates bytes 7..4. That can leave the second half-slot write without nospec_result even though the bytes being overwritten still require sanitization. Use the same slot index in the sanitization pre-check that the write path uses when updating slot_type[].", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72433", "url": "https://ubuntu.com/security/CVE-2026-72433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak This needs to test for nonzero retval.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72435", "url": "https://ubuntu.com/security/CVE-2026-72435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer() Sashiko pointed out that kfree_rcu() was called before rcu_assign_pointer() in handling the comment extension. Fix the order so that rcu_assign_pointer() called first.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72441", "url": "https://ubuntu.com/security/CVE-2026-72441", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ieee802154: fix kernel-infoleak in dgram_recvmsg() KMSAN reported a kernel-infoleak in move_addr_to_user(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:131 [inline] BUG: KMSAN: kernel-infoleak in _inline_copy_to_user include/linux/uaccess.h:205 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xcc/0x120 lib/usercopy.c:26 instrument_copy_to_user include/linux/instrumented.h:131 [inline] _inline_copy_to_user include/linux/uaccess.h:205 [inline] _copy_to_user+0xcc/0x120 lib/usercopy.c:26 copy_to_user include/linux/uaccess.h:236 [inline] move_addr_to_user+0x2e7/0x440 net/socket.c:302 ____sys_recvmsg+0x232/0x610 net/socket.c:2925 ... Uninit was stored to memory at: ieee802154_addr_to_sa include/net/ieee802154_netdev.h:369 [inline] dgram_recvmsg+0xa09/0xbe0 net/ieee802154/socket.c:739 The issue occurs because the `pan_id` field of `struct ieee802154_addr` is left uninitialized when the address mode is `IEEE802154_ADDR_NONE`. The execution flow is as follows: 1. `__ieee802154_rx_handle_packet()` declares a local `struct ieee802154_hdr hdr` on the stack. 2. `ieee802154_hdr_pull()` calls `ieee802154_hdr_get_addr()` to parse the source and destination addresses into this structure. 3. If the address mode is `IEEE802154_ADDR_NONE`, `ieee802154_hdr_get_addr()` previously only set the `mode` field, leaving the `pan_id` field containing uninitialized stack memory. 4. This uninitialized `pan_id` is later copied into a `struct sockaddr_ieee802154` in `dgram_recvmsg()` via `ieee802154_addr_to_sa()`. 5. Finally, `move_addr_to_user()` copies the socket address structure to user space, leaking the uninitialized bytes. Fix this by using `memset` to zero out the address structure in `ieee802154_hdr_get_addr()` when the mode is `IEEE802154_ADDR_NONE`.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72447", "url": "https://ubuntu.com/security/CVE-2026-72447", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: hold socket lock when dumping endpoints in sctp_diag SCTP_DIAG endpoint dumping was traversing endpoint address lists without holding lock_sock(), while those lists could change concurrently via socket operations (e.g., bindx changes). This creates a race where nla_reserve() counts addresses under RCU protection, but the subsequent copy may see fewer entries, potentially leaking uninitialized memory to userspace. Fix this by: - Taking a reference on each endpoint during hash traversal - Moving socket operations (lock_sock()) outside read_lock_bh() - Serializing address list access during dump - Reworking sctp_for_each_endpoint() to support restart-based traversal with (net, pos) tracking Also: - Add WARN_ON_ONCE() for inconsistent address counts - Fix idiag_states filtering for LISTEN vs association cases - Skip dumping endpoints being freed (ep->base.dead) - Move dump position tracking into iterator, removing cb->args[4] and its comment for sctp_ep_dump()., - Update the comment for cb->args[4] and remove the comment for unused cb->args[5] for sctp_sock_dump(). Note: traversal is restart-based and may re-scan buckets multiple times, but this is acceptable due to small bucket sizes and required to support sleeping-safe callbacks. This issue was reported by Nico Yip (@_cyeaa_) working with TrendAI Zero Day Initiative.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64553", "url": "https://ubuntu.com/security/CVE-2026-64553", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: psample: fix info leak in PSAMPLE_ATTR_DATA psample open codes nla_put() presumably to avoid wiping the data with 0s just to override it with packet data. This open coding is missing clearing the pad, however, each netlink attr is padded to 4B and data_len may not be divisible by 4B.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-72448", "url": "https://ubuntu.com/security/CVE-2026-72448", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix leak of SQ timestamp buffer on teardown The send-queue timestamp ring is allocated with qmem_alloc() when timestamping is used, but otx2_free_sq_res() never freed sq->timestamps, leaking that memory across ifdown and device removal. Add the missing qmem_free() alongside the other SQ companion buffers.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72450", "url": "https://ubuntu.com/security/CVE-2026-72450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: validate selector family and prefixlen during match syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72459", "url": "https://ubuntu.com/security/CVE-2026-72459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: aa_label_alloc use aa_label_free on alloc failure aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init(). Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72460", "url": "https://ubuntu.com/security/CVE-2026-72460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72466", "url": "https://ubuntu.com/security/CVE-2026-72466", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call. Second, after the post-peek p = xdr_inline_decode(xdr, 3 * sizeof(*p)); if (unlikely(!p)) return true; the short-header arm returns true without calling rpcrdma_bc_receive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path: rpcrdma_reply_handler() if (rpcrdma_is_bcall(r_xprt, rep)) return; /* bare return, skips out_post */ ... out_post: rpcrdma_post_recvs(r_xprt, credits + ...); Because rpcrdma_bc_receive_call() never ran, no one took rep, but rpcrdma_reply_handler still bare-returns past rpcrdma_rep_put() and rpcrdma_post_recvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rb_all_reps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches out_post and rpcrdma_post_recvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs. Fix by consulting xdr->end after the zero-length peek so the five __be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal out_norqst cleanup chain (rpcrdma_rep_put() plus rpcrdma_post_recvs()).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72476", "url": "https://ubuntu.com/security/CVE-2026-72476", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix possible use after free In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72479", "url": "https://ubuntu.com/security/CVE-2026-72479", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: mma8452: handle I2C read error(s) in mma8452_read() Currently, If i2c_smbus_read_i2c_block_data() fails but mma8452_set_runtime_pm_state() succeeds, mma8452_read() returns 0. As a result, the caller mma8452_read_raw() assumes the read was successful and proceeds to use a buffer containing uninitialized stack memory. Add proper checking of the I2C read return value and propagate errors to the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72481", "url": "https://ubuntu.com/security/CVE-2026-72481", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: ak8975: fix potential kernel stack memory leak Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72483", "url": "https://ubuntu.com/security/CVE-2026-72483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72484", "url": "https://ubuntu.com/security/CVE-2026-72484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: most: video: avoid double free on video register failure comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72489", "url": "https://ubuntu.com/security/CVE-2026-72489", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: nvec: fix use-after-free in nvec_rx_completed() In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72491", "url": "https://ubuntu.com/security/CVE-2026-72491", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72492", "url": "https://ubuntu.com/security/CVE-2026-72492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in same_client_has_lease() same_client_has_lease() returns an opinfo pointer from ci->m_op_list after dropping ci->m_lock without taking a reference. smb_grant_oplock() then dereferences that pointer in copy_lease() and when checking breaking_cnt. A concurrent close can remove the old lease from ci->m_op_list and drop the last reference before the caller uses the returned pointer, leading to a use-after-free. Take a reference when same_client_has_lease() selects an existing lease, drop any previous match while scanning, and release the returned reference in smb_grant_oplock() after copying the lease state.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72502", "url": "https://ubuntu.com/security/CVE-2026-72502", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF) When MTU is large, ip6_default_advmss() can return IPV6_MAXPLEN (65535). This is interpreted by TCP as mss_clamp, allowing the MSS to reach 65535. However, 0xFFFF is also used as a magic value GSO_BY_FRAGS in the kernel. If a TCP packet with gso_size=0xFFFF is passed to skb_segment(), it will be mistakenly treated as GSO_BY_FRAGS, leading to a NULL pointer dereference because local TCP packets do not use frag_list. Fix this by returning min(IPV6_MAXPLEN, GSO_BY_FRAGS - 1) (65534) from ip6_default_advmss() when MTU is large. Also update the stale comment in ip6_default_advmss() which suggested that IPV6_MAXPLEN is returned to mean \"any MSS\".", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74255", "url": "https://ubuntu.com/security/CVE-2026-74255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in tipc_l2_send_msg() Syzbot reported a slab-use-after-free in ipvlan_hard_header() when called from tipc_l2_send_msg(). The root cause is that tipc_disable_l2_media() calls synchronize_net() while b->media_ptr is still valid. This allows concurrent RCU readers to obtain the device pointer after synchronize_net() has finished. The pointer is cleared later in bearer_disable(), but without any subsequent synchronization, allowing the device to be freed while still in use by readers. Fix this by clearing b->media_ptr in tipc_disable_l2_media() before calling synchronize_net(). This is safe to do now because the call order in bearer_disable() was reversed in 0d051bf93c06 (\"tipc: make bearer packet filtering generic\") to call tipc_node_delete_links() (which needs the pointer) before disable_media(). https: //lore.kernel.org/netdev/6a2c1007.428ffe26.258b27.015d.GAE@google.com/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74256", "url": "https://ubuntu.com/security/CVE-2026-74256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check start and len are u32, so \tu64 last = start + len; evaluates start + len in 32-bit and wraps before storing it in last. The bounds check \tif (start >= offset + l || last > msg->sg.size) \t\treturn -EINVAL; can then be passed with an out-of-range start/len, after which the pop loop runs off the end of the scatterlist and sk_msg_shift_left() calls put_page() on the empty msg->sg.end slot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:sk_msg_shift_left net/core/filter.c:2957 [inline] RIP: 0010:____bpf_msg_pop_data net/core/filter.c:3103 [inline] RIP: 0010:bpf_msg_pop_data+0x753/0x1a10 net/core/filter.c:2984 Call Trace: bpf_prog_4cc92c278f4d5d56+0x1b1/0x1e8 bpf_prog_run_pin_on_cpu+0x107/0x320 include/linux/filter.h:746 sk_psock_msg_verdict+0x357/0x7f0 net/core/skmsg.c:934 tcp_bpf_send_verdict net/ipv4/tcp_bpf.c:420 [inline] tcp_bpf_sendmsg+0x766/0x1ae0 net/ipv4/tcp_bpf.c:583 __sock_sendmsg+0x153/0x1c0 net/socket.c:802 __sys_sendto+0x326/0x430 net/socket.c:2265 __x64_sys_sendto+0xe3/0x100 net/socket.c:2268 do_syscall_64+0x14c/0x480 entry_SYSCALL_64_after_hwframe+0x77/0x7f Widen the addition with a (u64) cast so the bound is evaluated in 64-bit and a len near U32_MAX no longer wraps below msg->sg.size. While here, change pop from int to u32. It counts bytes against the unsigned scatterlist lengths and can never be negative, so the signed type only invites sign-confusion in the pop loop.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64548", "url": "https://ubuntu.com/security/CVE-2026-64548", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data() When the scatterlist ring is full or nearly full, bpf_msg_push_data() enters a copy fallback path and computes copy + len for the page allocation size. Since len comes from BPF with arg3_type = ARG_ANYTHING and both are u32, a crafted len can wrap the sum to a small value, causing an undersized allocation followed by an out-of-bounds memcpy. BUG: unable to handle page fault for address: ffffed104089a402 Oops: Oops: 0000 [#1] SMP KASAN NOPTI Call Trace: __asan_memcpy (mm/kasan/shadow.c:105) bpf_msg_push_data (net/core/filter.c:2852 net/core/filter.c:2788) bpf_prog_9ed8b5711920a7d7+0x2e/0x36 sk_psock_msg_verdict (net/core/skmsg.c:934) tcp_bpf_sendmsg (net/ipv4/tcp_bpf.c:421 net/ipv4/tcp_bpf.c:584) __sys_sendto (net/socket.c:2206) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Add an overflow check before the allocation.", "cve_priority": "high", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74262", "url": "https://ubuntu.com/security/CVE-2026-74262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kcm: use WRITE_ONCE() when changing lower socket callbacks kcm_attach() replaces a live lower TCP socket's sk_data_ready and sk_write_space callbacks with KCM handlers, and kcm_unattach() restores them later. Those callback-pointer updates are still plain stores even though the same fields can be read and invoked concurrently on other CPUs. If another CPU observes an older callback snapshot after the live field has already been restored, callback execution can run with a mismatched target and sk_user_data state, leading to stale or misdirected wakeups. Use WRITE_ONCE() for the callback replacement and restore operations so these shared callback fields follow the same visibility contract already established by the earlier 4022 fixes.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74265", "url": "https://ubuntu.com/security/CVE-2026-74265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: initialize gdma queue id to INVALID_QUEUE_ID mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74267", "url": "https://ubuntu.com/security/CVE-2026-74267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek before restoring qlen Whenever codel drops packets during peek, it calls qdisc_tree_reduce_backlog. An issue arises because it calls qdisc_tree_reduce_backlog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlen_notify callback will be executed even though codel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a wild memory access when qfq has codel as a child: [ 36.339843][ T370] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 36.340408][ T370] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 36.340737][ T370] CPU: 2 UID: 0 PID: 370 Comm: tc Not tainted 7.1.0-rc5-00287-g66e13b626592 #87 PREEMPT(full) [ 36.341113][ T370] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 36.341357][ T370] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/sch_qfq.c:1369 (discriminator 2) net/sched/sch_qfq.c:1395 (discriminator 2)) sch_qfq [ 36.342221][ T370] RSP: 0018:ffff8881100ef370 EFLAGS: 00010216 [ 36.342422][ T370] RAX: 0000000000000000 RBX: ffff8881058a9568 RCX: dffffc0000000000 [ 36.342664][ T370] RDX: 1ffff11021064dc3 RSI: ffff888108326e00 RDI: dffffc0000000000 [ 36.342905][ T370] RBP: ffff8881058a8280 R08: dead000000000122 R09: 1bd5a00000000024 [ 36.343140][ T370] R10: fffffbfff2940329 R11: fffffbfff2940329 R12: 0000000000000000 [ 36.343383][ T370] R13: dead000000000100 R14: ffff8881058a9580 R15: ffff8881058a9578 [ 36.343631][ T370] FS: 00007fc04b0ca780(0000) GS:ffff888184fef000(0000) knlGS:0000000000000000 [ 36.343911][ T370] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.344116][ T370] CR2: 0000557c02c02000 CR3: 000000010e0ba000 CR4: 0000000000750ef0 [ 36.344359][ T370] PKRU: 55555554 [ 36.344481][ T370] Call Trace: ... [ 36.345054][ T370] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1487) sch_qfq [ 36.345222][ T370] qdisc_reset (net/sched/sch_generic.c:1057) [ 36.345503][ T370] __qdisc_destroy (net/sched/sch_generic.c:1096) [ 36.345677][ T370] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159) [ 36.346335][ T370] tc_get_qdisc (net/sched/sch_api.c:1528 net/sched/sch_api.c:1556) Fix this by only calling qdisc_tree_reduce_backlog in peek after the qlen is restored.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74276", "url": "https://ubuntu.com/security/CVE-2026-74276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: xilinx: use FIFO occupancy register to determine buffer size The method the driver uses to determine the size of the FIFO has a problem. What it currently does is this: It stops the SPI hardware and writes to the TX FIFO register until TX FIFO FULL asserts in the status register. But the hardware does not only have the FIFO, it also has a shift register which can hold a byte. This can be seen, when writing a byte to the FIFO (while the SPI hardware is stopped,) the TX FIFO EMPTY is still empty. So, if we have a FIFO size of 16 for example, the current method returns a 17. This is a problem, at least when using the driver in irq mode. The same size determined for the TX FIFO is also assumed for the RX FIFO. When a SPI transaction wants to write the amount of the FIFO size or more bytes, the following happens, for example with 16 bytes FIFO size: The driver stops the SPI hardware and writes 17 bytes to the TX FIFO and starts the SPI hardware and goes sleep. The hardware then shifts out 17 bytes (FIFO + shift register) and simultaneously reads bytes into the RX FIFO, but it only has 16 places, so it looses one byte. Then TX FIFO empty asserts, wakes the driver again, which has a fast path and reads 16 bytes from the RX FIFO, but before reading the last 17th byte (which is lost) it does this: \tsr = xspi->read_fn(xspi->regs + XSPI_SR_OFFSET); \tif (!(sr & XSPI_SR_RX_EMPTY_MASK)) { \t\txilinx_spi_rx(xspi); \t\trx_words--; \t} It reads the status register and checks if the RX FIFO is not empty. But it is empty in our case. So this check spins in a while loop forever locking the driver. This patch fixes the logic to determine the FIFO size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74279", "url": "https://ubuntu.com/security/CVE-2026-74279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: cavium/cpt - fix DMA cleanup using wrong loop index The sg_cleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74280", "url": "https://ubuntu.com/security/CVE-2026-74280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: marvell/octeontx - fix DMA cleanup using wrong loop index The sg_cleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74281", "url": "https://ubuntu.com/security/CVE-2026-74281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74282", "url": "https://ubuntu.com/security/CVE-2026-74282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: prevent snt_unacked underflow on CONN_ACK tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count from the unsigned 16-bit send counter snt_unacked without checking that it does not exceed the number of messages actually outstanding: \ttsk->snt_unacked -= msg_conn_ack(hdr); msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK message. If the ack count is larger than snt_unacked, the subtraction wraps to a near-maximum value, leaving tsk_conn_cong() permanently true and starving the connection of further transmits. Validate the ACK count at the start of the CONN_ACK block and drop the message if it acknowledges more messages than are outstanding. A peer (or, for a local connection, the connected peer socket) can otherwise wedge a TIPC connection's send side by sending an oversized connection ack.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74283", "url": "https://ubuntu.com/security/CVE-2026-74283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: require net admin for TIPCv2 netlink mutators TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAP_NET_ADMIN when an operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local unprivileged process can currently change TIPC state through commands such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and bearer enable/disable. The legacy TIPC netlink API already checks netlink_net_capable(..., CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which maps to the same namespace-aware CAP_NET_ADMIN check that netlink_net_capable() performs, so the behaviour matches the legacy path and keeps working for CAP_NET_ADMIN holders in a non-initial user namespace (containers). A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74284", "url": "https://ubuntu.com/security/CVE-2026-74284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_hfsc: Don't make class passive twice update_vf() is called from two places for the same class during a single dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last packets while dequeuing: 1. The child calls qdisc_tree_reduce_backlog(), which, now that the child is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns the class passive (cl_nactive is decremented up the hierarchy). 2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time) to charge the dequeued bytes. On the second call the class is already passive, but its child qdisc is still empty, so update_vf() arms go_passive again: if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) go_passive = 1; The leaf is then skipped by the cl_nactive == 0 check inside the loop, which does not clear go_passive, so the stale go_passive propagates to the parent and decrements its cl_nactive a second time. A parent that still has other active children is driven to cl_nactive == 0 and removed from the vttree, even though those siblings are still backlogged. They are never dequeued again and the qdisc stalls. Fix this by only arming go_passive when the class is actually active, so an already-passive class no longer triggers a second passive transition. The byte accounting (cl->cl_total += len) still runs for every ancestor, so dequeued bytes continue to be counted exactly once.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74287", "url": "https://ubuntu.com/security/CVE-2026-74287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate embedded address parameter length sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP, and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter. Later, sctp_process_param() and sctp_process_asconf_param() extract the embedded address parameter and pass it to af->from_addr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter. Validate that addr_param->p.length does not exceed the space available after the sctp_addip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds. This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64537", "url": "https://ubuntu.com/security/CVE-2026-64537", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bridge: cfm: reject invalid CCM interval at configuration time ccm_tx_work_expired() re-arms itself via queue_delayed_work() using the configured exp_interval converted by interval_to_us(). When exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range, interval_to_us() returns 0, causing the worker to fire immediately in a tight loop that allocates skbs until OOM. Fix this by validating exp_interval at configuration time: - Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range [BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the netlink policy so userspace cannot set an invalid value. - Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has not yet been configured (defaults to 0 from kzalloc).", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74288", "url": "https://ubuntu.com/security/CVE-2026-74288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fib_rules: Don't dump dying fib_rule in fib_rules_dump(). rocker_router_fib_event() calls fib_rule_get() during RCU dump. If the fib_rule is dying, refcount_inc() will complain about it. Let's call refcount_inc_not_zero() in fib_rules_dump().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74292", "url": "https://ubuntu.com/security/CVE-2026-74292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tegra: tegra210_ahub: Validate written enum value tegra_ahub_put_value_enum() reads e->values[item[0]] before checking whether item[0] is within the enum item range. The existing check therefore happens too late to prevent an out-of-range read of the values array. Move the check before the array access.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74293", "url": "https://ubuntu.com/security/CVE-2026-74293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: fsl_audmix: Validate written enum values fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src() convert the user-provided enum item with snd_soc_enum_item_to_val() before checking whether the item is within the enum's item count. The generic snd_soc_put_enum_double() helper performs that validation, but these callbacks use the converted value first: the clock-source path tests it with BIT(), and the output-source path indexes the prms transition table with it. Reject out-of-range enum items before converting them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74295", "url": "https://ubuntu.com/security/CVE-2026-74295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: hdac_hdmi: Validate written enum value hdac_hdmi_set_pin_port_mux() uses the written enum value to index the texts array before calling snd_soc_dapm_put_enum_double(), which validates that the value is within the enum item range. An out-of-range value can therefore make the driver read past the texts array before the helper rejects the write. Move the lookup after the helper has accepted the value.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74297", "url": "https://ubuntu.com/security/CVE-2026-74297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix undefined shift of user RQ WQE size set_rq_size() computes the RQ WQE size as \"1 << rq_wqe_shift\" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior. Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74305", "url": "https://ubuntu.com/security/CVE-2026-74305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Tighten cgroup storage cookie checks for prog arrays The fix in commit abad3d0bad72 (\"bpf: Fix oob access in cgroup local storage\") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path. Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74312", "url": "https://ubuntu.com/security/CVE-2026-74312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/vdpa: validate virtqueue index in mmap and fault paths vhost_vdpa_mmap() and vhost_vdpa_fault() use vma->vm_pgoff as a virtqueue index for get_vq_notification(), but they do not validate that the index is smaller than v->nvqs. The ioctl path already performs both a bounds check and array_index_nospec(), but the mmap/fault path only checks that the index fits in u16. This allows an out-of-range queue index to reach driver-specific get_vq_notification() callbacks. Fix this by extracting a unified vhost_vdpa_get_vq_notification() helper that validates the queue index against v->nvqs and applies array_index_nospec() before calling the driver callback. Both the mmap and fault paths use this helper, and the bounds checking is consolidated into a single location. From source inspection, the most defensible impact is out-of-bounds access in the callback path, potentially leading to invalid PFN remaps and crash/DoS.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74313", "url": "https://ubuntu.com/security/CVE-2026-74313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vduse: hold vduse_lock across IDR lookup in open path vduse_dev_open() looks up struct vduse_dev through the IDR and then acquires dev->lock only after vduse_lock has been dropped. This leaves a window where a concurrent VDUSE_DESTROY_DEV can remove the same object from the IDR and free it before the open path locks the device, leading to a use-after-free. Close this race by keeping vduse_lock held until dev->lock has been acquired in the open path, matching the lock ordering already used by the destroy path.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74320", "url": "https://ubuntu.com/security/CVE-2026-74320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, \"mode\", &len) is just written over either the static \"640x480-16@60\" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74321", "url": "https://ubuntu.com/security/CVE-2026-74321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs() In the beginning of the loop, we try to obtain a locked delayed ref head, if 'locked_ref' is currently NULL, by calling btrfs_select_ref_head(), which can return an error pointer. If the error pointer is -EAGAIN we do a continue and go back to the beginning of the loop, which will not try again to call btrfs_select_ref_head() since 'locked_ref' is no longer NULL but it's ERR_PTR(-EAGAIN), and then we do: spin_lock(&locked_ref->lock); against a ERR_PTR(-EAGAIN) value, generating an invalid pointer dereference. Fix this by ensuring that 'locked_ref' is set to NULL when btrfs_select_ref_head() returns ERR_PTR(-EAGAIN) and incrementing 'count' as well, to prevent infinite looping. We do this by doing a goto to the bottom of the loop that already sets 'locked_ref' to NULL and does a cond_resched(), with an increment to 'count' right before the goto. These measures were in place before the refactoring in commit 0110a4c43451 (\"btrfs: refactor __btrfs_run_delayed_refs loop\") but were unintentionally lost afterwards.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74327", "url": "https://ubuntu.com/security/CVE-2026-74327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmalloc: fix NULL pointer dereference in is_vm_area_hugepages() find_vm_area() can return NULL if the given address is not a valid vmalloc area. Check the return value before dereferencing it to avoid a kernel crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74329", "url": "https://ubuntu.com/security/CVE-2026-74329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: unregister PM notifier on watchdog unregister watchdog_register_device() registers wdd->pm_nb when WDOG_NO_PING_ON_SUSPEND is set, but watchdog_unregister_device() does not remove it. This leaves an embedded notifier block on the PM notifier chain after the watchdog device has been unregistered. A later suspend/resume notification can then call watchdog_pm_notifier() with a stale watchdog_device pointer, or at minimum after wdd->wd_data has been cleared by watchdog_dev_unregister(). Unregister the PM notifier before tearing down the watchdog device.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74330", "url": "https://ubuntu.com/security/CVE-2026-74330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs: fix lockless traversals of ->s_children Having the parent directory locked protects entries from removal by another thread, but it does *not* protect cursors from being moved around by lseek() - or freed, for that matter.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74331", "url": "https://ubuntu.com/security/CVE-2026-74331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Fix recursive lock in device_cache_fw_images() A recursive locking deadlock can occur in the firmware loader's power management notification handler. During system suspend or hibernation preparation, fw_pm_notify() calls device_cache_fw_images(). This function acquires fw_lock to set the firmware cache state to FW_LOADER_START_CACHE and then iterates over all devices using dpm_for_each_dev() while still holding the lock. For each device, dev_cache_fw_image() schedules asynchronous work to cache the firmware. If memory allocation for the async work entry fails (e.g., in out-of-memory conditions), async_schedule_node_domain() falls back to executing the work function synchronously in the current thread. The synchronous execution path (__async_dev_cache_fw_image() -> cache_firmware() -> request_firmware() -> assign_fw()) attempts to acquire fw_lock again. Since the current thread already holds fw_lock, this results in a recursive locking deadlock. Fix this by releasing fw_lock immediately after updating the cache state and before calling dpm_for_each_dev(). The lock is only needed to protect the state update. Concurrent firmware requests will correctly see the FW_LOADER_START_CACHE state and use the piggyback mechanism, which is independently protected by its own fwc->name_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74339", "url": "https://ubuntu.com/security/CVE-2026-74339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Clear variable event pointer on read snd_seq_read() copies a queued variable-length event header to userspace before expanding the payload. Queued variable-length events use SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first extension cell. The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the copy, but it leaves data.ext.ptr untouched. A userspace sequencer client can therefore write a direct variable event to itself and read back the extension-cell kernel address from the returned header. Clear the temporary header pointer before copy_to_user(). The original queued event remains unchanged and is still passed to snd_seq_expand_var_event(), so payload expansion keeps using the internal chain.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74340", "url": "https://ubuntu.com/security/CVE-2026-74340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74346", "url": "https://ubuntu.com/security/CVE-2026-74346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix OOB read during CQ MR registration Sashiko pointed out an unrelated bug during a previous patch: https://sashiko.dev/#/patchset/20260512183852.614045-1-jmoroni%40google.com This change fixes the bug by eliminating the cqmr->split field which was not being set properly and instead just checks the CQ resize feature flag directly. The cqmr->split field essentially tracks whether IRDMA_FEATURE_CQ_RESIZE is set, but it was not being set until CQ creation time, which is _after_ CQ memory registration (the only other place where it is referenced). As a result, it would always be false during MR registration and would therefore cause irdma_handle_q_mem to populate cqmr->shadow even for GEN_2 HW and beyond: cqmr->shadow = (dma_addr_t)arr[req->cq_pages]; The issue is that for GEN_2 and beyond, req->cq_pages may be exactly equal to iwmr->page_cnt and therefore equal to the size of arr, which would cause an OOB read by one.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74348", "url": "https://ubuntu.com/security/CVE-2026-74348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2/dlm: require a ref for locking_state debugfs open debug_lockres_open() copies inode->i_private into struct debug_lockres and debug_lockres_release() later drops that pointer with dlm_put(). That only works if open successfully pins the struct dlm_ctxt. Today open calls dlm_grab(dlm) but ignores its return value. Once the last domain unregister has removed the context from dlm_domains, dlm_grab() returns NULL, yet open still stores the raw pointer and returns success. The later release path is outside the debugfs removal barrier, so it can call dlm_put() after dlm_free_ctxt_mem() has freed the context. KASAN reports this as a slab-use-after-free in dlm_put() called from debug_lockres_release(). Fail the open when dlm_grab() cannot acquire the reference and unwind the seq_file private state before returning. That keeps locking_state from handing out a file descriptor whose release path does not own the dlm_ctxt. The buggy scenario involves two paths, with each column showing the order within that path: locking_state debugfs open: last domain unregister: 1. debug_lockres_open() reads 1. dlm_unregister_domain() calls inode->i_private. dlm_complete_dlm_shutdown(). 2. debug_lockres_open() calls 2. shutdown removes the dlm_ctxt from dlm_grab(dlm) and gets NULL. dlm_domains. 3. open still stores the raw dlm 3. final teardown reaches pointer in dl->dl_ctxt and dlm_free_ctxt_mem() and frees it. returns success. 4. debug_lockres_release() later calls dlm_put(dl->dl_ctxt). Validation reproduced this kernel report: KASAN slab-use-after-free in dlm_put+0x82/0x200 RIP: 0033:0x7f4d349bc9e0 The buggy address belongs to the object at ffff888103a3c000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 816 bytes inside of freed 2048-byte region [ffff888103a3c000, ffff888103a3c800) Write of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) dlm_put+0x82/0x200 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) kasan_check_range+0x105/0x1b0 (?:?) debug_lockres_release+0x53/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) dlm_put+0x9/0x200 (?:?) debug_lockres_release+0x5c/0x80 (fs/ocfs2/dlm/dlmdebug.c:587) full_proxy_release+0x67/0x90 (?:?) __fput+0x1df/0x4b0 (?:?) do_raw_spin_lock+0x10f/0x1b0 (?:?) fput_close_sync+0xd2/0x170 (?:?) __x64_sys_close+0x55/0x90 (?:?) do_syscall_64+0x10c/0x640 (arch/x86/entry/syscall_64.c:87) irqentry_exit+0xac/0x6e0 (?:?) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?) Freed by task stack: kasan_save_stack+0x33/0x60 (?:?) kasan_save_track+0x14/0x30 (?:?) kasan_save_free_info+0x3b/0x60 (?:?) __kasan_slab_free+0x5f/0x80 (?:?) kfree+0x30f/0x580 (?:?) dlm_put+0x1ce/0x200 (?:?) dlm_unregister_domain+0xf6/0xb30 (?:?) o2cb_cluster_disconnect+0x6b/0x90 (?:?) ocfs2_cluster_disconnect+0x41/0x70 (?:?) ocfs2_dlm_shutdown+0x1c4/0x220 (?:?) ocfs2_dismount_volume+0x38a/0x550 (?:?) generic_shutdown_super+0xc3/0x220 (?:?) kill_block_super+0x29/0x60 (?:?) deactivate_locked_super+0x66/0xe0 (?:?) cleanup_mnt+0x13d/0x210 (?:?) task_work_run+0xfa/0x170 (?:?) exit_to_user_mode_loop+0xd6/0x430 (?:?) do_syscall_64+0x3cb/0x640 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74349", "url": "https://ubuntu.com/security/CVE-2026-74349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject FITRIM ranges shorter than a cluster ocfs2_trim_mainbm() trims the global bitmap in cluster units, but its too-short range validation only checks sb->s_blocksize. On filesystems with a cluster size larger than the block size, a FITRIM range that is at least one block but shorter than one cluster is accepted and shifted down to len == 0. The later start + len - 1 and len -= ... arithmetic then underflows and can drive trimming past the requested range. Reject ranges shorter than s_clustersize instead. That preserves the existing -EINVAL behavior for requests that cannot discard even one allocation unit and keeps zero-cluster trims out of the group walk.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74351", "url": "https://ubuntu.com/security/CVE-2026-74351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: lockres teardown: 1. ocfs2_dlm_seq_start()/next() 1. file release or another owner copies struct ocfs2_lock_res teardown reaches 2. ocfs2_dlm_seq_show() formats ocfs2_lock_res_free() the copied row 2. the lockres is removed from the 3. ocfs2_dlm_lvb() follows the tracking list copied sb_lvbptr 3. the owner frees the original lockres container Validation reproduced this kernel report: KASAN slab-use-after-free in ocfs2_dlm_seq_show+0x1bd/0x430 RIP: 0033:0x7f8ec4b1e29d The buggy address belongs to the object at ffff88810a1e0800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 368 bytes inside of freed 1024-byte region [ffff88810a1e0800, ffff88810a1e0c00) Read of size 1 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ocfs2_dlm_seq_show+0x1bd/0x430 (fs/ocfs2/dlmglue.c:3137) srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x19f/0x330 kasan_report+0xe0/0x110 seq_read_iter+0x29d/0x790 seq_read+0x20a/0x280 find_held_lock+0x2b/0x80 rcu_read_unlock+0x18/0x70 full_proxy_read+0x9e/0xd0 vfs_read+0x12c/0x590 ksys_read+0xd2/0x170 do_user_addr_fault+0x65a/0x890 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 ocfs2_file_open+0x13e/0x300 do_dentry_open+0x233/0x7f0 vfs_open+0x5a/0x1b0 path_openat+0x66d/0x1540 do_file_open+0x186/0x2b0 do_sys_openat2+0xce/0x150 __x64_sys_openat+0xd0/0x140 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 ocfs2_file_release+0x138/0x260 __fput+0x1df/0x4b0 fput_close_sync+0xd2/0x170 __x64_sys_close+0x55/0x90 do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74359", "url": "https://ubuntu.com/security/CVE-2026-74359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: configfs_lookup(): don't leave ->s_dentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74363", "url": "https://ubuntu.com/security/CVE-2026-74363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs commit 4f375ade6aa9 (\"bpf: Avoid RCU context warning when unpinning htab with internal structs\") moved inode cleanup from ->free_inode() into ->destroy_inode() to avoid sleeping in RCU context when calling bpf_any_put(). However this removed the RCU delay on freeing the inode itself and the cached symlink body (i_link), both of which can be accessed by RCU pathwalk (pick_link, may_lookup etc.). This causes a use-after-free when a concurrent unlinkat() drops the last inode reference and destroy_inode() frees the inode immediately, while another task is still walking the path in RCU mode and reads inode->i_opflags (offset +2) inside current_time() -> is_mgtime(). KASAN reports: BUG: KASAN: slab-use-after-free in is_mgtime include/linux/fs.h:2313 Read of size 2 at addr ffff8880407e4282 (offset +2 = i_opflags) The rules (per Al Viro): ->destroy_inode() called immediately, can sleep, use for blocking cleanup e.g. bpf_any_put() ->free_inode() called after RCU grace period, use for freeing inode and anything RCU-accessible e.g. i_link Fix: split the two concerns properly: - keep bpf_any_put() in bpf_destroy_inode() since it is blocking and needs to run promptly - introduce bpf_free_inode() to handle kfree(i_link) and free_inode_nonrcu() with proper RCU delay, preventing the UAF", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74376", "url": "https://ubuntu.com/security/CVE-2026-74376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: md/raid10: reset read_slot when reusing r10bio for discard put_all_bios() always drops devs[i].bio, but it only drops devs[i].repl_bio when r10_bio->read_slot < 0. If discard reuses an r10bio that was previously used for a read, read_slot can still be non-negative, and discard cleanup can skip bio_put() on repl_bio. Reset read_slot to -1 when preparing an r10bio for discard so the replacement bio is always released correctly.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74379", "url": "https://ubuntu.com/security/CVE-2026-74379", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dax/kmem: account for partial discontiguous resource upon removal When dev_dax_kmem_probe() partially succeeds (at least one range is mapped) but a subsequent range fails request_mem_region() or add_memory_driver_managed(), the probe silently continues, ultimately returning success, but with the corresponding range resource NULL'ed out. dev_dax_kmem_remove() iterates over all dax_device ranges regardless of if the underlying resource exists. When remove_memory() is called later, it returns 0 because the memory was never added which causes dev_dax_kmem_remove() to incorrectly assume the (nonexistent) resource can be removed and attempts cleanup on a NULL pointer. Fix this by skipping these ranges altogether, noting that these cases are considered success, such that the cleanup is still reached when all actually-added ranges are successfully removed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74382", "url": "https://ubuntu.com/security/CVE-2026-74382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: prevent unbounded recursion in offload rollback Quan Sun reported [1] a stack overflow in cls_bpf_offload_cmd(). Reproducer on netdevsim: add a skip_sw cls_bpf filter, set the bpf_tc_accept debugfs knob to 0, then `tc filter replace`. The replace calls tc_setup_cb_replace() which fails. cls_bpf_offload_cmd() then swaps prog/oldprog and recursively calls itself to roll back. But bpf_tc_accept=0 makes the rollback fail too, which triggers yet another rollback frame with the same arguments, and so on until the stack is exhausted. bpf_tc_accept is just a convenient knob for the reproducer. Any driver whose tc_setup_cb_replace() fails twice in a row can hit the same loop, so this is not a netdevsim-only issue. Two ways to fix it: 1) Have the rollback call tc_setup_cb_add() on oldprog instead of re-entering cls_bpf_offload_cmd(). 2) Mark the rollback frame with a flag and skip a second-level rollback from inside it. Go with (2). It is the smaller change and keeps the original behaviour: the rollback still goes through tc_setup_cb_replace(), so the driver gets one real chance to restore its state. If that attempt also fails, we just return the original error instead of recursing. [1]: https://lore.kernel.org/bpf/ce5a6005-3c5e-4696-9e05-eba9461dc860@std.uestc.edu.cn/T/#u", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74384", "url": "https://ubuntu.com/security/CVE-2026-74384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: fix flex array size in struct nvme_ns_head struct nvme_ns_head contains a flexible array member, current_path[], which is indexed using the NUMA node ID: head->current_path[numa_node_id()] The structure is currently allocated as: size = sizeof(struct nvme_ns_head) + (num_possible_nodes() * sizeof(struct nvme_ns *)); head = kzalloc(size, GFP_KERNEL); This allocation assumes that NUMA node IDs are sequential and densely packed from 0 .. num_possible_nodes() - 1. While this assumption holds on many systems, it is not always true on some architectures such as powerpc. On some powerpc systems, NUMA node IDs can be sparse. For example: NUMA: NUMA node(s): 6 NUMA node0 CPU(s): 80-159 NUMA node8 CPU(s): 0-79 NUMA node252 CPU(s): NUMA node253 CPU(s): NUMA node254 CPU(s): NUMA node255 CPU(s): That is, the possible/online NUMA node IDs are: 0, 8, 252, 253, 254, 255 In this case: num_possible_nodes() = 6 So memory is allocated for only 6 entries in current_path[]. However, the array is later indexed using the actual NUMA node ID. As a result, accesses such as: head->current_path[8] or head->current_path[252] goes out of bounds, leading to the following KASAN splat: ================================================================== BUG: KASAN: slab-out-of-bounds in nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] Write of size 8 at addr c00020003bda35b8 by task kworker/u641:2/1997 CPU: 1 UID: 0 PID: 1997 Comm: kworker/u641:2 Not tainted 7.1.0-rc5-dirty #14 PREEMPT(lazy) Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Workqueue: async async_run_entry_fn Call Trace: [c000200037fa7510] [c0000000021c23d4] dump_stack_lvl+0x88/0xdc (unreliable) [c000200037fa7540] [c0000000009fda90] print_report+0x22c/0x67c [c000200037fa7630] [c0000000009fd508] kasan_report+0x108/0x220 [c000200037fa7740] [c0000000009fff48] __asan_store8+0xe8/0x120 [c000200037fa7760] [c008000018e76474] nvme_mpath_revalidate_paths+0x22c/0x290 [nvme_core] [c000200037fa7800] [c008000018e6556c] nvme_update_ns_info+0x4a4/0x5e0 [nvme_core] [c000200037fa7a50] [c008000018e66270] nvme_alloc_ns+0x6d8/0x1a70 [nvme_core] [c000200037fa7c20] [c008000018e679fc] nvme_scan_ns+0x3f4/0x630 [nvme_core] [c000200037fa7d10] [c00000000031f22c] async_run_entry_fn+0x9c/0x3a0 [c000200037fa7db0] [c0000000002fa544] process_one_work+0x414/0xa10 [c000200037fa7ec0] [c0000000002fbf00] worker_thread+0x320/0x640 [c000200037fa7f80] [c00000000030d0f8] kthread+0x278/0x290 [c000200037fa7fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 Allocated by task 1997 on cpu 1 at 35.928317s: The buggy address belongs to the object at c00020003bda3000 which belongs to the cache kmalloc-rnd-15-2k of size 2048 The buggy address is located 16 bytes to the right of allocated 1448-byte region [c00020003bda3000, c00020003bda35a8) The buggy address belongs to the physical page: Memory state around the buggy address: c00020003bda3480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c00020003bda3500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c00020003bda3580: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc ^ c00020003bda3600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00020003bda3680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Fix this by allocating the flexible array using nr_node_ids instead of num_possible_nodes(). Since nr_node_ids represents the maximum possible NUMA node IDs, indexing current_path[] using numa_node_id() becomes safe even on systems with sparse node IDs.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74390", "url": "https://ubuntu.com/security/CVE-2026-74390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs The irdma_copy_user_pgaddrs function loops through all of the umem DMA blocks to populate the PBLEs and will stop when either the last DMA block is reached or palloc->total_cnt is reached. The issue is that the logic for checking palloc->total_cnt would only work for non-zero values. When irdma_setup_pbles is called with lvl==0, it calls irdma_copy_user_pgaddrs with palloc->total_cnt==0, which means the only way to break out of the loop is to reach the last umem DMA block, which means it could end up going beyond the fixed size of 4 iwmr->pgaddrmem array that is used in the lvl==0 case. In the case of QP/CQ/SRQ rings, the value of lvl is determined by a separate input (for example, req.cq_pages in the case of a CQ). So, we must perform explicit checking to ensure we don't overflow the pgaddrmem array if the user provides a umem that consists of more blocks than their provided req.cq_pages.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74394", "url": "https://ubuntu.com/security/CVE-2026-74394", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: fix integer overflow in immediate data length check imm_buf->len is a user-controlled uint32_t received from the network. Adding it to imm_data_offset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing req_size to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sg_init_one(). Use check_add_overflow() to detect wrapping before the comparison.", "cve_priority": "critical", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74395", "url": "https://ubuntu.com/security/CVE-2026-74395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT() links event_sub into sub_list before initializing the fields used by the shared error path. If eventfd_ctx_fdget() then fails, the unwind path dereferences event_sub->ev_file in uverbs_uobject_put() and calls subscribe_event_xa_dealloc() with an unset xa_key_level1. subscribe_event_xa_alloc() creates the XA entry exactly once for a given key_level1, on the first occurrence of that key. The unwind path must therefore call subscribe_event_xa_dealloc() exactly once for it as well. Enforce that by adding devx_key_in_sub_list() and calling subscribe_event_xa_dealloc() only when the last matching pending entry is being cleaned up.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74398", "url": "https://ubuntu.com/security/CVE-2026-74398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD addrconf_dad_failure() transitions ifp->state from DAD to POSTDAD via addrconf_dad_end(), which drops ifp->lock on return. The lock is re-acquired after net_info_ratelimited(). A concurrent ipv6_del_addr() can take the lock in that window, set ifp->state to DEAD and run list_del_rcu(&ifp->if_list). addrconf_dad_failure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dad_work. The work calls ipv6_del_addr() again, hitting the already-poisoned list entry: general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:ipv6_del_addr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconf_dad_stop+0x113/0x140 addrconf_dad_work+0x28c/0x430 process_one_work+0x1eb/0x3b0 worker_thread+0x4d/0x400 kthread+0x104/0x140 ret_from_fork+0x35/0x40 Fold the addrconf_dad_end() logic into addrconf_dad_failure() under a single ifp->lock critical section. The STABLE_PRIVACY branch temporarily drops ifp->lock around address regeneration, so at lock_errdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74399", "url": "https://ubuntu.com/security/CVE-2026-74399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: evm: terminate and bound the evm_xattrs read buffer evm_read_xattrs() allocates size + 1 bytes, fills them from the list of enabled xattrs, and then passes strlen(temp) to simple_read_from_buffer(). When no configured xattrs are enabled, the fill loop stores nothing and temp[0] remains uninitialized, so strlen() reads beyond initialized memory. Explicitly terminate the buffer after allocation, use snprintf() for each formatted line, and pass the accumulated length, without risk of truncation, to simple_read_from_buffer().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64544", "url": "https://ubuntu.com/security/CVE-2026-64544", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents pefile_digest_pe_contents() computes the trailing-data hash length as pelen - (hashed_bytes + certs_size). A crafted PE can make the addition exceed pelen, causing the unsigned subtraction to underflow to ~4 GiB. This is passed to crypto_shash_update() which reads out of bounds and panics on unmapped vmalloc guard pages. BUG: unable to handle page fault for address: ffffc900038d8000 Oops: Oops: 0000 [#1] SMP KASAN NOPTI RIP: 0010:sha256_blocks_generic (lib/crypto/sha256.c:152) Call Trace: __sha256_update (lib/crypto/sha256.c:208) crypto_sha256_update (crypto/sha256.c:142) verify_pefile_signature (crypto/asymmetric_keys/verify_pefile.c:436) kexec_kernel_verify_pe_sig (kernel/kexec_file.c:151) __do_sys_kexec_file_load (kernel/kexec_file.c:406) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Kernel panic - not syncing: Fatal exception Validate that the addition does not overflow and the result does not exceed pelen before the subtraction. Return -ELIBBAD on failure.", "cve_priority": "medium", "cve_public_date": "2026-07-27 21:17:00 UTC" }, { "cve": "CVE-2026-74402", "url": "https://ubuntu.com/security/CVE-2026-74402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: atmel-sha204a - fix blocking and non-blocking rng logic The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message. Tested on an Atmel SHA204A device. Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74408", "url": "https://ubuntu.com/security/CVE-2026-74408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: fix OOB access from firmware tx status queue ID ath_tx_edma_tasklet() accesses sc->tx.txq[ts.qid] where ts.qid is a 4-bit hardware field (0-15), but the txq array only has ATH9K_NUM_TX_QUEUES (10) entries. A qid >= 10 causes an OOB array access. Add a bounds check on ts.qid before using it as an array index.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74410", "url": "https://ubuntu.com/security/CVE-2026-74410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA buffer In rtw_pci_rx_napi(), new_len is computed as the sum of pkt_len (14-bit descriptor field, max 16383) and pkt_offset (drv_info_sz + shift, both firmware-controlled). The result can exceed RTK_PCI_RX_BUF_SIZE (11478), causing an out-of-bounds read from the pre-allocated DMA buffer when skb_put_data copies new_len bytes. The USB transport already validates this (rtw_usb_rx_data_put checks against RTW_USB_MAX_RECVBUF_SZ); the PCIe path does not. Add a check that new_len does not exceed the DMA buffer size.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74416", "url": "https://ubuntu.com/security/CVE-2026-74416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix memory leak in radeon_ring_restore() on lock failure radeon_ring_restore() takes ownership of the data buffer allocated by radeon_ring_backup(). The caller (radeon_gpu_reset()) only frees it in the non-restore branch; in the restore branch it relies on radeon_ring_restore() to free it. If radeon_ring_lock() fails, the function returned early without calling kvfree(data), leaking the ring backup buffer on every GPU reset that fails at the lock stage. During repeated GPU resets this causes cumulative kernel memory exhaustion. Free data before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74424", "url": "https://ubuntu.com/security/CVE-2026-74424", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: fix NULL pointer dereference for a console without vc_data fbcon_new_modelist() runs when a framebuffer's modelist changes. For each console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and passes the vc_num to fbcon_set_disp(). This assumes a console with a mode set has a vc_data, but it can be NULL. fbcon_set_disp() sets fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the mode set after the vc_data is freed. fbcon_new_modelist() then dereferences the NULL vc_data. Keep fb_display[i].mode set only while the console has a vc_data. Check vc_data before setting the mode in fbcon_set_disp(), and clear the mode in fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips such consoles.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74426", "url": "https://ubuntu.com/security/CVE-2026-74426", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: fix NULL pointer dereference in afs_get_tree() afs_alloc_sbi() uses kzalloc for memory allocation. And, if ctx->dyn_root is not null, as->cell and as->volume are null. In trace_afs_get_tree() they are dereferenced. KASAN error message: KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550 include/trace/events/afs.h:1365 Call Trace: trace_afs_get_tree include/trace/events/afs.h:1365 [inline] afs_get_tree+0x922/0x1350 fs/afs/super.c:599 vfs_get_tree+0x8e/0x300 fs/super.c:1572 do_new_mount fs/namespace.c:3011 [inline] path_mount+0x14a5/0x2220 fs/namespace.c:3341 do_mount fs/namespace.c:3354 [inline] __do_sys_mount fs/namespace.c:3562 [inline] __se_sys_mount fs/namespace.c:3539 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3539 do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74427", "url": "https://ubuntu.com/security/CVE-2026-74427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix netns teardown to cancel the preallocation charger Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0). Also, if net->live is false because the afs netns is being deleted, make afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid requeuing the charger. (This was found by AI review).", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74438", "url": "https://ubuntu.com/security/CVE-2026-74438", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: sun4i-ss - Remove insecure and unused rng_alg Remove sun4i_ss_rng, as it is insecure and unused: - It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing locking and has a buffer overflow. sun4i_ss_prng_generate() fails to fill the entire buffer with cryptographic random bytes, because it rounds the destination length down and also doesn't actually wait for the hardware to be ready before pulling bytes from it. - No user of this code is known. It's usable only theoretically via the \"rng\" algorithm type of AF_ALG. But userspace actually just uses the actual Linux RNG (/dev/random etc) instead. And rng_algs don't contribute entropy to the actual Linux RNG either. (This may have been confused with hwrng, which does contribute entropy.) The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen and discovered by Atuin - Automated Vulnerability Discovery Engine There's no point in fixing all these vulnerabilities individually when this is unused code, so let's just remove it.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74578", "url": "https://ubuntu.com/security/CVE-2026-74578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: algif_skcipher - force synchronous processing on trees without ctx->state The AIO/async path in skcipher_recvmsg() passes the socket-wide ctx->iv directly into the skcipher request. After io_submit() the socket lock is dropped and the request is processed asynchronously, so a concurrent sendmsg(ALG_SET_IV) can overwrite ctx->iv and make the in-flight request run under an attacker-controlled IV. For CTR/stream modes this is IV/keystream reuse and lets an unprivileged user recover the plaintext of a concurrent operation. Snapshotting ctx->iv into per-request storage for the async path is not sufficient. For ciphers with statesize == 0 - which includes cbc and ctr - the MSG_MORE inter-chunk IV chaining is carried solely by the in-place req->iv writeback, which a snapshot redirects into per-request memory that af_alg_free_resources() releases on completion, silently producing wrong output. Writing the IV back from the completion callback instead is not possible either: that would require lock_sock() there, but the callback can run in softirq/atomic context, so it must not sleep. Make the operation synchronous instead, which removes both the IV race and any writeback race. This is equivalent to the upstream resolution, commit fcc77d33a34c (\"net: Remove support for AIO on sockets\"), which removed the AIO socket path across net/ entirely and so produces the same end state for this file. This patch deviates from that commit deliberately: rather than removing AIO socket support tree-wide, which would be far too invasive for stable, it removes only the AIO branch in crypto/algif_skcipher.c. io_submit() now completes synchronously; AF_ALG async is rarely used in practice. The -EIOCBQUEUED check in skcipher_recvmsg() is now dead but harmless, and is left alone to keep the fix minimal. Tested on 6.6.y: attacker IV injection dropped from 2296/200000 to 0/200000 after the change; MSG_MORE chunked CTR output bit-identical to single-shot.", "cve_priority": "medium", "cve_public_date": "2026-08-16 09:16:00 UTC" }, { "cve": "CVE-2026-64600", "url": "https://ubuntu.com/security/CVE-2026-64600", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.", "cve_priority": "medium", "cve_public_date": "2026-07-23 06:16:00 UTC" }, { "cve": "CVE-2026-64187", "url": "https://ubuntu.com/security/CVE-2026-64187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fail recovery on a committed log item with no regions If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367)", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64266", "url": "https://ubuntu.com/security/CVE-2026-64266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before returning from fuse_ref_folio() fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues. Fix this by locking the request in fuse_ref_folio() before returning.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64268", "url": "https://ubuntu.com/security/CVE-2026-64268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: bound Read Response placement to the RREAD length In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siw_check_sge() resolves and validates the sink memory only on the first fragment (the if (!*mem) branch), and siw_rresp_check_ntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->more_ddp_segs guard). A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siw_rx_data() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege. Bound every segment before placement, exactly as siw_proc_send() and siw_proc_write() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer. This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64269", "url": "https://ubuntu.com/security/CVE-2026-64269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg When the server answers an RTRS READ, rdma_write_sg() builds the source scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the peer. Its length is taken directly from the wire descriptor: plist->length = le32_to_cpu(id->rd_msg->desc[0].len); rd_msg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -> process_io_req() -> process_read()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide local_dma_lkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to max_chunk_size. msg_id and off are bounded against queue_depth and max_chunk_size in rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not checked against the chunk size. A peer that advertises desc[0].len larger than max_chunk_size can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer. Reject a descriptor length above max_chunk_size, mirroring the existing off >= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64271", "url": "https://ubuntu.com/security/CVE-2026-64271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: touchwin - reset the packet index on every complete packet tw_interrupt() accumulates each non-zero serial byte into a fixed three-byte buffer with a running index that is only reset once a full packet has been received *and* the device's two Y bytes agree: \ttw->data[tw->idx++] = data; \tif (tw->idx == TW_LENGTH && tw->data[1] == tw->data[2]) { \t\t... \t\ttw->idx = 0; \t} The reset is gated on tw->data[1] == tw->data[2], a value the device controls. A malicious, malfunctioning or counterfeit Touchwindow peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the index reaches TW_LENGTH without the equality holding, is never reset, and keeps growing, so tw->data[tw->idx++] walks off the end of the three-byte array and the rest of the heap-allocated struct tw, one attacker-chosen byte at a time -- an unbounded, device-driven heap out-of-bounds write. Reset the index on every completed packet and report an event only when the two Y bytes match, like the other serio touchscreen drivers do.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64273", "url": "https://ubuntu.com/security/CVE-2026-64273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: iforce - bound the device-reported force-feedback effect index iforce_process_packet() handles a status report (packet id 0x02) by taking a force-feedback effect index straight from the device wire and using it to address the per-effect state array: \ti = data[1] & 0x7f; \tif (data[1] & 0x80) { \t\tif (!test_and_set_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) \t\t\t... \t} else if (test_and_clear_bit(FF_CORE_IS_PLAYED, \t\t\t\t iforce->core_effects[i].flags)) { \t\t... \t} The index is masked only with 0x7f, so it ranges 0..127, but core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index of 32..127 the test_and_set_bit()/test_and_clear_bit() is an out-of-bounds single-bit read-modify-write past the array. core_effects[] is the second-to-last member of struct iforce, so the write lands in the trailing members and beyond the embedding kzalloc()'d iforce_serio / iforce_usb object. data[1] is unvalidated device payload on both transports (the USB interrupt endpoint and serio), and the status path is not gated on force feedback being present, so a malicious or counterfeit device can set or clear a bit at an attacker-chosen offset past the object. Reject an out-of-range index instead of indexing with it. Bound against the array dimension IFORCE_EFFECTS_MAX rather than dev->ff->max_effects so the check guarantees memory safety regardless of how many effects the device registered. A legitimate \"effect started/stopped\" status always carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are unaffected; the neighbouring mark_core_as_ready() loop is already bounded and is left untouched.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64274", "url": "https://ubuntu.com/security/CVE-2026-64274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: goodix - clamp the device-reported contact count goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer \tu8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS]; which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped: \tts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f; The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write. Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64275", "url": "https://ubuntu.com/security/CVE-2026-64275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: elan_i2c - prevent division by zero and arithmetic underflow The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for x_traces or y_traces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe. Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1. Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios. Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64276", "url": "https://ubuntu.com/security/CVE-2026-64276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count rmi_f30_map_gpios() allocates gpioled_key_map with min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f30_attention() iterates the full f30->gpioled_count (device query register, range 0..31) and dereferences gpioled_key_map[i], and input->keycodemax is set to the full gpioled_count while input->keycode points at the 6-entry allocation. A device that reports gpioled_count > 6 with GPIO support enabled therefore causes an out-of-bounds read on the attention interrupt and out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls, which bound the index only against keycodemax. This is the same defect as the F3A handler, which was copied from F30. Size the keymap for the full gpioled_count; the mapping loop still assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64277", "url": "https://ubuntu.com/security/CVE-2026-64277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count rmi_f3a_initialize() takes the GPIO count from the device query register (f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127). rmi_f3a_map_gpios() then allocates gpio_key_map with min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but rmi_f3a_attention() iterates the full gpio_count and dereferences gpio_key_map[i], and input->keycodemax is set to the full gpio_count while input->keycode points at the 6-entry allocation. A device that reports gpio_count > 6 therefore causes an out-of-bounds read of gpio_key_map[] on every attention interrupt, and out-of-bounds accesses through the input core's default keymap ioctls: EVIOCGKEYCODE reads past the buffer (leaking adjacent slab memory to user space) and EVIOCSKEYCODE writes a caller-controlled value past it, for any process able to open the evdev node, since input_default_getkeycode() and input_default_setkeycode() only bound the index against keycodemax. Size the keymap for the full gpio_count. The mapping loop is unchanged: it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END) entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills) and are skipped when reporting.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64279", "url": "https://ubuntu.com/security/CVE-2026-64279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter deregistration race Adapters can be looked up by their id using i2c_get_adapter() which takes a reference to the embedded struct device. Remove the adapter from the IDR before tearing it down during deregistration (and on registration failure) to make sure its resources are not accessed after having been freed (e.g. the device name).", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64604", "url": "https://ubuntu.com/security/CVE-2026-64604", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in guest mode so that a future change can have update CR8 intercepts during vCPU creation, without running afoul of get_vmcs12()'s lockdep assertion. ------------[ cut here ]------------ debug_locks && !(lock_is_held(&(&vcpu->mutex)->dep_map) || !refcount_read(&vcpu->kvm->users_count)) WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879 WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879 Modules linked in: CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline] RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879 Call Trace: apic_update_ppr arch/x86/kvm/lapic.c:984 [inline] kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023 kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986 kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847 kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201 kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f No functional change intended.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64296", "url": "https://ubuntu.com/security/CVE-2026-64296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: bound uniname advance in exfat_find_dir_entry() In exfat_find_dir_entry(), each TYPE_EXTEND (file name) entry advances the output pointer by a fixed amount while the loop guard only tracks the accumulated name length: \tif (++order == 2) \t\tuniname = p_uniname->name; \telse \t\tuniname += EXFAT_FILE_NAME_LEN; \tlen = exfat_extract_uni_name(ep, entry_uniname); \tname_len += len; \tunichar = *(uniname+len); \t*(uniname+len) = 0x0; uniname grows by EXFAT_FILE_NAME_LEN (15) per name entry, but name_len grows only by the actual extracted length, which is shorter when a name fragment contains an early NUL. The only guard is `name_len >= MAX_NAME_LENGTH`, so a crafted directory with many short name fragments lets uniname run far past the p_uniname->name[MAX_NAME_LENGTH + 3] buffer while name_len stays small, causing an out-of-bounds read and write at *(uniname+len). The sibling extractor exfat_get_uniname_from_ext_entry() already stops on a short fragment (the lockstep `len != EXFAT_FILE_NAME_LEN` guard added in commit d42334578eba (\"exfat: check if filename entries exceeds max filename length\")); exfat_find_dir_entry() never got the equivalent. Track the per-entry write offset as a count and reject a fragment once the offset, or the offset plus the extracted length, would exceed MAX_NAME_LENGTH, before forming the output pointer.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64298", "url": "https://ubuntu.com/security/CVE-2026-64298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: include MAY_WRITE in open permission mask for O_TRUNC POSIX requires write permission to truncate a file, so an open() that specifies O_TRUNC must be authorized for write access regardless of the O_ACCMODE access mode. nfs_open_permission_mask() builds the access mask passed to nfs_may_open(), which is the local authorization gate for OPENs the client serves itself from a cached write delegation via the can_open_delegated() path in nfs4_try_open_cached(). The mask is derived from O_ACCMODE alone, so an open(O_RDONLY | O_TRUNC) against a file the caller cannot write requests only MAY_READ and passes the local check. The OPEN is then satisfied locally and the truncation is issued to the server as a SETATTR(size=0) over the delegation stateid, which the server accepts under standard write-delegation semantics. POSIX requires that this open fail with EACCES. Include MAY_WRITE in the mask whenever O_TRUNC is set so the local check matches the access the server would have enforced.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64299", "url": "https://ubuntu.com/security/CVE-2026-64299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent out-of-bounds read in glob matching String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it. regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint. Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64303", "url": "https://ubuntu.com/security/CVE-2026-64303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: terminate the RX channel on TX prepare failure path When dmaengine_prep_slave_sg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free. Terminate the RX channel before returning on the TX prepare failure path.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64306", "url": "https://ubuntu.com/security/CVE-2026-64306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: drbg - Fix returning success on failure in CTR_DRBG drbg_ctr_generate() sometimes returns success when it fails, leaving the output buffer uninitialized. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64312", "url": "https://ubuntu.com/security/CVE-2026-64312", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - restore callback for non-parallel fallback pcrypt installs pcrypt_aead_done() on the child AEAD request before trying to submit it through padata. If padata_do_parallel() returns -EBUSY, pcrypt falls back to calling the child AEAD directly. That fallback must not keep the padata completion callback. Otherwise an asynchronous completion runs pcrypt_aead_done() even though the request was never enrolled in padata. Restore the original request callback and callback data before calling the child AEAD directly. This keeps the fallback path aligned with a direct AEAD request while leaving the parallel path unchanged.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64313", "url": "https://ubuntu.com/security/CVE-2026-64313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: ecc - Fix carry overflow in vli multiplication The carry flag calculation fails when r01.m_high is saturated (0xFFFFFFFFFFFFFFFF) and addition of lower bits overflows. The condition (r01.m_high < product.m_high) doesn't handle the case where r01.m_high == product.m_high and an additional carry exists from lower-bit overflow. When commit 3c4b23901a0c (\"crypto: ecdh - Add ECDH software support\") introduced crypto/ecc.c, it split the muladd() function in the micro-ecc library into separate mul_64_64() and add_128_128() helpers. It seems the check got lost in translation. Add proper handling for this boundary by accounting for the carry from the lower addition.", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64315", "url": "https://ubuntu.com/security/CVE-2026-64315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64316", "url": "https://ubuntu.com/security/CVE-2026-64316", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - use print_hex_dump_devel to guard key hex dumps Use print_hex_dump_devel() for dumping sensitive key material in *_setkey() and gen_split_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64317", "url": "https://ubuntu.com/security/CVE-2026-64317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge \"SL\" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64318", "url": "https://ubuntu.com/security/CVE-2026-64318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: partitions: aix: bound the pp_count scan to the ppe array aix_partition() reads the physical volume descriptor into a fixed-size struct pvd and then scans its physical-partition-extent array: \tint numpps = be16_to_cpu(pvd->pp_count); \t... \tfor (i = 0; i < numpps; i += 1) { \t\tstruct ppe *p = pvd->ppe + i; \t\t... \t\tlp_ix = be16_to_cpu(p->lp_ix); pvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a fixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the on-disk pp_count. pp_count is an unvalidated __be16 read straight from the descriptor, so a crafted AIX image with pp_count larger than 1016 drives the loop to read pvd->ppe[i] past the end of the allocation (up to 65535 entries, ~2 MB out of bounds). The partition scan runs without mounting anything, when a block device with a crafted AIX/IBM partition table appears (an attacker-supplied image attached with losetup -P, or a device auto-scanned by udev), via msdos_partition() -> aix_partition(). Clamp the scan to the number of entries the ppe[] array can hold.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64322", "url": "https://ubuntu.com/security/CVE-2026-64322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate sparing table length as an entry count, not a byte count udf_load_sparable_map() accepts a sparing table when \tsizeof(*st) + le16_to_cpu(st->reallocationTableLen) > sb->s_blocksize is false, i.e. it treats reallocationTableLen as a number of BYTES that must fit in the block. But the table is walked as an array of 8-byte sparingEntry elements: \tfor (i = 0; i < le16_to_cpu(st->reallocationTableLen); i++) { \t\tstruct sparingEntry *entry = &st->mapEntry[i]; \t\t... entry->origLocation ... \t} in udf_get_pblock_spar15() and udf_relocate_blocks(). A reallocationTableLen of N therefore passes the check whenever sizeof(*st) + N <= blocksize, yet the consumers index sizeof(*st) + N * sizeof(struct sparingEntry) bytes -- up to ~8x the block. On a crafted UDF image this is an out-of-bounds read in udf_get_pblock_spar15(); udf_relocate_blocks() additionally feeds the same length to udf_update_tag(), whose crc_itu_t() reads far past the block, and its memmove() through st->mapEntry[] is an out-of-bounds write. Validate reallocationTableLen as the entry count it is, with struct_size().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64323", "url": "https://ubuntu.com/security/CVE-2026-64323", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate VAT header length against the VAT inode size udf_load_vat() takes the virtual partition's start offset straight from the on-disk VAT 2.0 header without checking it against the VAT inode size: \tmap->s_type_specific.s_virtual.s_start_offset = \t\tle16_to_cpu(vat20->lengthHeader); \tmap->s_type_specific.s_virtual.s_num_entries = \t\t(sbi->s_vat_inode->i_size - \t\t\tmap->s_type_specific.s_virtual.s_start_offset) >> 2; lengthHeader is a fully attacker-controlled 16-bit value. If it exceeds the VAT inode size, the s_num_entries subtraction underflows to a huge count, which defeats the \"block > s_num_entries\" bound in udf_get_pblock_virt15(); and on the ICB-inline path that function reads \t((__le32 *)(iinfo->i_data + s_start_offset))[block] so a large s_start_offset indexes past the inode's in-ICB data. Mounting a crafted UDF image with a virtual (VAT) partition then triggers an out-of-bounds read. Reject a VAT whose header length does not leave room for at least one entry within the VAT inode.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64324", "url": "https://ubuntu.com/security/CVE-2026-64324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: validate free block extents against the partition length udf_free_blocks() checks the logical block number and count against the partition length, but drops the extent offset from that final bound. A crafted extent can pass the guard while logicalBlockNum + offset + count points past the partition, which later indexes past the space bitmap array. A single ftruncate(2) on a file backed by such an extent reliably panics the kernel. This is a local availability issue. On desktop systems where UDisks/polkit allows the active user to mount removable UDF media without CAP_SYS_ADMIN, an unprivileged local user can supply the crafted filesystem and trigger the panic by truncating a writable file on it. Systems that require root or CAP_SYS_ADMIN to mount the image have a higher prerequisite. No confidentiality or integrity impact is claimed: the reproduced primitive is an out-of-bounds read of a bitmap pointer slot followed by a kernel panic. Use the already computed logicalBlockNum + offset + count value for the partition length check. Also make load_block_bitmap() reject an out-of-range block group before indexing s_block_bitmap[], so corrupted callers cannot walk past the flexible array.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64330", "url": "https://ubuntu.com/security/CVE-2026-64330", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Validate SVID index in svdm_consume_modes() In svdm_consume_modes(), the SVID value is read from pmdata->svids using pmdata->svid_index as an array index without bounds validation: paltmode->svid = pmdata->svids[pmdata->svid_index]; If pmdata->svid_index is driven beyond SVID_DISCOVERY_MAX (16), it results in an out-of-bounds read of the pmdata->svids array. Because pd_mode_data is embedded inside struct tcpm_port, indexing past svids reads into adjacent fields. In particular: - At index 16, it reads the altmodes count. - At index 18 and beyond, it reads into altmode_desc[], which contains partner-supplied SVDM Discovery Modes VDOs. By injecting a chosen SVID into altmode_desc[0].vdo and driving svid_index to 20, the partner can force paltmode->svid to be loaded with an arbitrary, partner- chosen SVID, which is then registered via typec_partner_register_altmode(). Fix this by validating that pmdata->svid_index is non-negative and strictly less than pmdata->nsvids before accessing the pmdata->svids array inside svdm_consume_modes().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64331", "url": "https://ubuntu.com/security/CVE-2026-64331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usbip: vudc: fix NULL deref in vep_dequeue() vep_alloc_request() wasn't initializing vrequest->udc, so cancellations on the FunctionFS AIO path were arriving in vep_dequeue without a valid UDC reference. Since vrequest->udc is never actually properly used anywhere, we opt to remove it, and update vep_dequeue to obtain a reference to the udc with ep_to_vudc(), consistent with the other vep_ ops. AFAICT this bug has existed for ~10 years. Seems that nobody has really stressed the FunctionFS AIO path on usbip's vudc. I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints via AIO. Before the fix, running `usbip attach` from the host would cause the guest to oops with the following backtrace: Call trace: vep_dequeue+0x1c/0xe4 (P) usb_ep_dequeue+0x14/0x20 ffs_aio_cancel+0x24/0x34 __arm64_sys_io_cancel+0xb0/0x124 do_el0_svc+0x68/0x100 el0_svc+0x18/0x5c el0t_64_sync_handler+0x98/0xdc el0t_64_sync+0x154/0x158", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64332", "url": "https://ubuntu.com/security/CVE-2026-64332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ulpi: fix memory leak on registration failure The allocated device name is never freed on early ULPI device registration failures. Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64333", "url": "https://ubuntu.com/security/CVE-2026-64333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix write buffer corruption The digi_write_inb_command() is supposed to wait for the write urb to become available or return an error, but instead it updates the transfer buffer and tries to resubmit the urb on timeout. To make things worse, for commands like break control where no timeout is used, the driver would corrupt the urb immediately due to a broken jiffies comparison (on 32-bit machines this takes five minutes of uptime to trigger due to INITIAL_JIFFIES). Fix this by adding the missing return on timeout and waiting indefinitely when no timeout has been specified as intended. This issue was (sort of) flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64334", "url": "https://ubuntu.com/security/CVE-2026-64334", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix hard lockup on disconnect If submitting the OOB write urb fails persistently (e.g if the device is being disconnected) the driver would loop indefinitely with interrupts disabled. Check for urb submission errors when sending OOB commands to avoid hanging if, for example, open(), set_termios() or close() races with a physical disconnect. This is issue was flagged by Sashiko when reviewing an unrelated change to the driver.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64335", "url": "https://ubuntu.com/security/CVE-2026-64335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: digi_acceleport: fix broken rx after throttle If the port is closed while throttled, the read urb is never resubmitted and the port will not receive any further data until the device is reconnected (or the driver is rebound). Clear the throttle flags and submit the urb if needed when opening the port.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64336", "url": "https://ubuntu.com/security/CVE-2026-64336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: keyspan_pda: fix information leak The write() callback is supposed to return the number of characters accepted or a negative errno. Since the addition of write fifo support the keyspan_pda implementation will however return the number characters submitted to the device if the write urb is not already in use. If this number is larger than the number of characters passed to write(), the line discipline continues writing data from beyond the tty write buffer. Fix the information leak by making sure that keyspan_pda_write_start() returns zero on success as intended.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64337", "url": "https://ubuntu.com/security/CVE-2026-64337", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: unmap request DMA on queue failure mtu3_gadget_queue() maps the request before checking whether the QMU GPD ring can accept another transfer. the request is returned with -EAGAIN before it is linked on the endpoint request list if mtu3_prepare_transfer() fails. Normal completion and dequeue paths unmap requests from mtu3_req_complete(), but this error path never reaches that helper, so the DMA mapping is left active. Unmap the request before returning from the failed queue path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64338", "url": "https://ubuntu.com/security/CVE-2026-64338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: misc: uss720: unregister parport on probe failure uss720_probe() registers a parport before reading the 1284 register used to detect unsupported Belkin F5U002 adapters. If get_1284_register() fails, the error path drops the driver private data and the USB device reference, but leaves the parport device registered. Leaving the port registered is more than a private allocation leak: parport_register_port() has already reserved a parport number and registered the parport bus device, while pp->private_data still points at the private data that the common error path is about to release. Undo the pre-announce registration in the get_1284_register() failure branch before jumping to the common private-data cleanup path. Clear priv->pp first, matching the disconnect path and avoiding a stale pointer in the private data. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64340", "url": "https://ubuntu.com/security/CVE-2026-64340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: legousbtower: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64342", "url": "https://ubuntu.com/security/CVE-2026-64342", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: iowarrior: fix use-after-free on disconnect Submitted write URBs are not stopped on close() and therefore need to be stopped unconditionally on disconnect() to avoid use-after-free in the completion handler.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64343", "url": "https://ubuntu.com/security/CVE-2026-64343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: ldusb: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64344", "url": "https://ubuntu.com/security/CVE-2026-64344", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: idmouse: fix use-after-free on disconnect race mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749ab34d9 (\"locking/mutex: Document that mutex_unlock() is non-atomic\") [2] 2b9d9e0a9ba0 (\"locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked\")", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64346", "url": "https://ubuntu.com/security/CVE-2026-64346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: Fix use-after-free in gadget_match_driver The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usb_del_gadget() frees the udc memory (e.g., via mode-switch work) while gadget_match_driver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed: [39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : __pi_strcmp+0x20/0x140 [39430.911441][ T1171] lr : gadget_match_driver+0x34/0x60 ... [39430.911890][ T1171] usb_gadget_register_driver_owner+0x50/0xf8 [39430.911910][ T1171] gadget_dev_desc_UDC_store+0xf4/0x140 [39430.931308][ T1171] configfs_write_iter+0xec/0x134 [39430.957058][ T1171] Workqueue: events_freezable __dwc3_set_mode [39430.957287][ T1171] dwc3_gadget_exit+0x34/0x8c [39430.957304][ T1171] __dwc3_set_mode+0xc0/0x664 Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usb_gadget_release() routine to the core. When the gadget is added, usb_add_gadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usb_gadget_release() drops the reference to the udc and then calls the gadget's release routine.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64347", "url": "https://ubuntu.com/security/CVE-2026-64347", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler The OTG branch of composite_setup() falls back to the first configuration when none is selected: \tif (cdev->config) \t\tconfig = cdev->config; \telse \t\tconfig = list_first_entry(&cdev->configs, \t\t\t\t\t struct usb_configuration, list); \tif (!config) \t\tgoto done; \t... \tmemcpy(req->buf, config->descriptors[0], value); list_first_entry() never returns NULL. On an empty list it returns container_of() of the list head. So the \"if (!config)\" check is dead. When cdev->configs is empty, config points at the head inside struct usb_composite_dev. config->descriptors[0] reads whatever sits at that offset. The memcpy copies up to w_length bytes of it into the response buffer. cdev->configs can be empty in two cases. One is a teardown race on gadget unbind with a control transfer in flight. The other is a driver that sets is_otg before it adds a config. A reproducer that holds cdev->configs empty triggers a KASAN fault in this branch. Use list_first_entry_or_null() so the existing check does its job.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64350", "url": "https://ubuntu.com/security/CVE-2026-64350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info() cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and stream_rings array, but leaves stream_ctx_array allocated. Free the stream context array before falling through to the stream_rings cleanup path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64351", "url": "https://ubuntu.com/security/CVE-2026-64351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: bound RX frame length in kalmia_rx_fixup() kalmia_rx_fixup() computes usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIA_HEADER_LENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usb_packet_length to about 65530. That bypasses the usb_packet_length < ether_packet_length truncation path. The device-supplied ether_packet_length, a le16 up to 65535 read from header_start[2], then drives a memcmp() and the following skb_trim() and skb_pull() past the end of the rx buffer. The rx buffer is hard_mtu * 10, which is 14000 bytes. That is an out of bounds read. Require both the start and end framing headers to be present before subtracting them, on every loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64359", "url": "https://ubuntu.com/security/CVE-2026-64359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read: INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230 The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev(): __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780 The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read. Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64360", "url": "https://ubuntu.com/security/CVE-2026-64360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfs/hfsplus: zero-initialize buffer in hfs_bnode_read hfs_bnode_read() can return early without writing to the output buffer when is_bnode_offset_valid() fails or when check_and_correct_requested_ length() corrects the length to zero. Callers such as hfs_bnode_read_ u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the result unconditionally, leading to KMSAN uninit-value reports. Rather than initializing at each individual call site, zero the buffer at the start of hfs_bnode_read() before any validation checks. This ensures all callers in both hfs and hfsplus get a deterministic zero value regardless of which early-return path is taken.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64362", "url": "https://ubuntu.com/security/CVE-2026-64362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: lg-g15: cancel pending work on remove to fix a use-after-free lg_g15_data is allocated with devm and holds a work item. The report handlers schedule that work straight from device input. lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key, and lg_g510_leds_event() does it too. The worker dereferences the lg_g15_data back through container_of. The driver had no remove callback and never cancelled the work. So if a report scheduled the work and the keyboard was then unplugged, devres freed lg_g15_data while the work was still pending or running, and the worker touched freed memory. This is a use-after-free. It is reachable as a race on device unplug. Add a remove callback that cancels the work before devres frees the state. g15->work is only initialized for the models that schedule it (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the cancel on g15->work.func to avoid cancelling a work that was never set up. The g15 NULL test mirrors the one already in lg_g15_raw_event().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68091", "url": "https://ubuntu.com/security/CVE-2026-68091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: wacom: stop hardware after post-start probe failures wacom_parse_and_register() starts HID hardware before registering inputs and initializing pad LEDs/remotes. Those later steps can fail, but their error paths currently release Wacom resources without stopping the HID hardware. Route post-hid_hw_start() failures through hid_hw_stop() before releasing driver resources. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64370", "url": "https://ubuntu.com/security/CVE-2026-64370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference via get_pid() and stores it in timer.it.cpu.pid. If the subsequent posix_cpu_timer_set() call fails, the function returns immediately without calling posix_cpu_timer_del() to release the pid reference, causing a leak. Fix it by calling posix_cpu_timer_del() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64372", "url": "https://ubuntu.com/security/CVE-2026-64372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: pcc: fix use-after-free and double free in _OSC evaluation pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the two-phase _OSC negotiation. Between the two calls it freed output.pointer but left output.length unchanged. Since acpi_evaluate_object() treats a non-zero length with a non-NULL pointer as an existing buffer to write into, the second call wrote into freed memory (use-after-free). The subsequent kfree(output.pointer) at out_free then freed the same pointer a second time (double free). Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER after freeing the first result, so ACPICA allocates a fresh buffer for each phase independently.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64373", "url": "https://ubuntu.com/security/CVE-2026-64373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Fix hotplug-suspend race during reboot During system reboot, cpufreq_suspend() is called via the kernel_restart() -> device_shutdown() path. Unlike the normal system suspend path, the reboot path does not call freeze_processes(), so userspace processes and kernel threads remain active. This allows CPU hotplug operations to run concurrently with cpufreq_suspend(). The original code has no synchronization with CPU hotplug, leading to a race condition where governor_data can be freed by the hotplug path while cpufreq_suspend() is still accessing it, resulting in a null pointer dereference: Unable to handle kernel NULL pointer dereference Call Trace: do_kernel_fault+0x28/0x3c cpufreq_suspend+0xdc/0x160 device_shutdown+0x18/0x200 kernel_restart+0x40/0x80 arm64_sys_reboot+0x1b0/0x200 Fix this by adding cpus_read_lock()/cpus_read_unlock() to cpufreq_suspend() to block CPU hotplug operations while suspend is in progress. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64374", "url": "https://ubuntu.com/security/CVE-2026-64374", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT. If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it. A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed. When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU. As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64403", "url": "https://ubuntu.com/security/CVE-2026-64403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: validate option length before reading conf opt value l2cap_get_conf_opt() derives the option length from the attacker-controlled opt->len field and immediately dereferences opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a raw pointer for the default case) before any caller has confirmed that opt->len bytes are present in the buffer. The callers (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and l2cap_conf_rfc_get()) only detect a malformed option afterwards, once the running length has gone negative, by which point the out-of-bounds read has already executed. An existing post-hoc length check keeps the garbage value from being consumed, so this is not a data leak in the current control flow. It is still a validate-after-use ordering bug: up to 4 bytes are read past the end of the buffer before it is known to contain them, and it is fragile to future changes in the callers. Fix it at the source. Pass the end of the buffer into l2cap_get_conf_opt() and refuse to touch opt->val unless the full option (header + value) fits. Each caller computes an end pointer once before the loop and checks the return value directly instead of inferring the error from a negative length.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64408", "url": "https://ubuntu.com/security/CVE-2026-64408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: pin L2CAP connection during netdev registration bnep_add_connection() reads the L2CAP connection without holding the channel lock, then passes its HCI device to register_netdev(). Controller teardown can clear and release that connection concurrently, leaving the network device registration path to dereference a freed parent device. Take a reference to the L2CAP connection while holding the channel lock. Retain it until register_netdev() has taken the parent device reference.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64411", "url": "https://ubuntu.com/security/CVE-2026-64411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: terminate table name before find_table_lock() update_counters() and compat_update_counters() forward a user-supplied 32-byte table name to find_table_lock() without NUL-terminating it. On a lookup miss, find_inlist_lock() calls try_then_request_module(..., \"%s%s\", \"ebtable_\", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte. BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) __request_module (kernel/module/kmod.c:150) do_update_counters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) update_counters (net/bridge/netfilter/ebtables.c:1440) do_ebt_set_ctl (net/bridge/netfilter/ebtables.c:2573) nf_setsockopt (net/netfilter/nf_sockopt.c:101) ip_setsockopt (net/ipv4/ip_sockglue.c:1424) raw_setsockopt (net/ipv4/raw.c:847) __sys_setsockopt (net/socket.c:2393) ... compat_do_replace() shares the same unterminated name via compat_copy_ebt_replace_from_user(); terminate it there too so all find_table_lock() callers behave alike. The other callers already terminate the name after the copy.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64412", "url": "https://ubuntu.com/security/CVE-2026-64412", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: module names must be null-terminated We need to explicitly check the length, else we may pass non-null terminated string to request_module().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64420", "url": "https://ubuntu.com/security/CVE-2026-64420", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mfd: cros_ec: Delay dev_set_drvdata() until probe success If ec_device_probe() fails, cros_ec_class_release releases memory for the cros_ec_dev structure. However, because the drvdata was already set, sub-drivers like cros_ec_typec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when cros_ec_typec attempts to access &typec->ec->ec->dev on a device that has already been released. Move dev_set_drvdata() to ensure that the pointer is only made available once all initialization steps have succeeded. sysfs: cannot create duplicate filename '/class/chromeos/cros_ec' Call trace: sysfs_do_create_link_sd+0x94/0xdc sysfs_create_link+0x30/0x44 device_add_class_symlinks+0x90/0x13c device_add+0xf0/0x50c ec_device_probe+0x150/0x4f0 platform_probe+0xa0/0xe0 ... BUG: KASAN: invalid-access in __memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOT_MODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: events_unbound deferred_probe_work_func Call trace: __memcpy+0x44/0x230 cros_ec_check_features+0x60/0xcc [cros_ec_proto] cros_typec_probe+0xe8/0x6e0 [cros_ec_typec] platform_probe+0xa0/0xe0", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64422", "url": "https://ubuntu.com/security/CVE-2026-64422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP socket state. The sysctl is stored as an `int` but copied into the `u32` `tp->reordering` field for new sockets, so negative writes wrap to large values. With `tcp_mtu_probing=2`, the wrapped value can overflow the `tcp_mtu_probe()` size calculation and drive the MTU probing path into an out-of-bounds read. Route `tcp_reordering` writes through `proc_dointvec_minmax()` and require it to be at least 1. Also require `tcp_max_reordering` to be at least 1 so the configured maximum cannot become negative either. When registering the table for a non-init network namespace, relocate `extra2` pointers that refer into `init_net.ipv4` so the `tcp_reordering` upper bound follows that namespace's `tcp_max_reordering`. Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`. This keeps the send queue and window checks from being bypassed through signed integer overflow.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64423", "url": "https://ubuntu.com/security/CVE-2026-64423", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: remove multicast group from hash table on device destruction When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through the multicast list and calls ip_ma_put() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mc_hash). Since the device remains published in dev->ip_ptr until after ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs. Fix this by unlinking the multicast group from mc_hash using ip_mc_hash_remove() before scheduling it for reclamation. BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276 Call Trace: dump_stack_lvl+0x67/0x90 print_report+0x175/0x7c0 kasan_report+0x147/0x180 ip_check_mc_rcu+0x149/0x3f0 udp_v4_early_demux+0x36d/0x12d0 ip_rcv_finish_core+0xb8b/0x1390 ip_rcv_finish+0x54/0x120 NF_HOOK+0x213/0x2b0 __netif_receive_skb+0x126/0x340 process_backlog+0x4f2/0xf00 __napi_poll+0x92/0x2c0 net_rx_action+0x583/0xc60 handle_softirqs+0x236/0x7f0 do_softirq+0x57/0x80 Allocated by task 2239: kasan_save_track+0x3e/0x80 __kasan_kmalloc+0x72/0x90 ____ip_mc_inc_group+0x31a/0xa40 __ip_mc_join_group+0x334/0x3f0 do_ip_setsockopt+0x16fa/0x2010 ip_setsockopt+0x3f/0x90 do_sock_setsockopt+0x1ad/0x300 Freed by task 0: kasan_save_track+0x3e/0x80 kasan_save_free_info+0x40/0x50 __kasan_slab_free+0x3a/0x60 __rcu_free_sheaf_prepare+0xd4/0x220 rcu_free_sheaf+0x36/0x190 rcu_core+0x8d9/0x12f0 handle_softirqs+0x236/0x7f0", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64425", "url": "https://ubuntu.com/security/CVE-2026-64425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item commit 10dc95939817 (\"io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop\") fixed the obvious case where io_worker_handle_work() took one exit-bit snapshot before draining pending work, but the fix stops one level too early. io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT after the first linked item has started, the remaining linked items can still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue running after exit has begun. Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64429", "url": "https://ubuntu.com/security/CVE-2026-64429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: eic-sprd: use raw_spinlock_t in the irq startup path sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller state through sprd_eic_update(), which takes sprd_eic->lock with spin_lock_irqsave(). The callback can be reached from irq_startup() while setting up a requested IRQ. That path is not sleepable, but on PREEMPT_RT a regular spinlock_t becomes a sleeping lock. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the request_threaded_irq() -> __setup_irq() -> irq_startup() -> sprd_eic_irq_unmask() -> sprd_eic_update() carrier and used the original spin_lock_irqsave(&sprd_eic->lock) edge. Lockdep BUG: sleeping function called from invalid context hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv] sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv] sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv] sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv] __setup_irq.constprop.0+0xd/0x30 [vuln_msv] Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The locked section only serializes MMIO register updates and does not contain sleepable operations, so keeping it non-sleeping is appropriate for the irqchip callbacks.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64430", "url": "https://ubuntu.com/security/CVE-2026-64430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid calling pci_irq_vector() from hardirq context ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive the vector number. pci_irq_vector() calls msi_get_virq() that takes a mutex and can therefore trigger \"scheduling while atomic\" splats: BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedule_preempt_disabled+0x28/0x50 __mutex_lock.constprop.0+0x848/0x908 __mutex_lock_slowpath+0x18/0x30 mutex_lock+0x4c/0x60 msi_domain_get_virq+0xe8/0x138 pci_irq_vector+0x2c/0x60 ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf] __handle_irq_event_percpu+0x70/0x3a8 handle_irq_event+0x48/0x100 handle_edge_irq+0x100/0x1c8 ... Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64432", "url": "https://ubuntu.com/security/CVE-2026-64432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns In the analysis pass of $LogFile journal replay, log_replay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcns_follow=1 and an action log record with lcns_follow=2 produces a kernel slab out-of-bounds write at mount time: BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount Two attacker-controlled fields can drive j+i past the allocated page_lcns[] array: 1. dp->lcns_follow (capacity) can be smaller than lrh->lcns_follow. 2. lrh->target_vcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge size_t. Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL. This mirrors the bounds-check pattern added in commit b2bc7c44ed17 (\"fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot\") and commit 0ca0485e4b2e (\"fs/ntfs3: validate rec->used in journal-replay file record check\").", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68090", "url": "https://ubuntu.com/security/CVE-2026-68090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Plug race against a concurrent OOM disable syzbot reported a puzzling splat: WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20 stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup. Though the provided console log lacks this warning and instead has the following a few seconds before the splat: ODEBUG: Out of memory. ODEBUG disabled So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects: debug_object_assert_init() if (!debug_objects_enabled) \treturn; obj = alloc(); \t\t\t\tif (!obj) { \t\t\t\t\t\t\t// Out of memory \tdebug_objects_enabled = false; free_objects(); obj = lookup_or_alloc(); // The lookup failed because the other side // removed the objects, so this returns // an error code as the object in question // is not statically initialized \tif (!IS_ERR_OR_NULL(obj)) \treturn; if (!obj) { \tdebug_oom(); return; } print(...) if (!debug_objects_enabled) return; fixup(...) The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional. This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object. Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-64435", "url": "https://ubuntu.com/security/CVE-2026-64435", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: Fix data races of skb_queue_len() readers on audit_queue Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races. All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn() KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30 read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0 value changed: 0x00000001 -> 0x00000000 ================================================================== Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side. [PM: line length tweak]", "cve_priority": "low", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64436", "url": "https://ubuntu.com/security/CVE-2026-64436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: af_key: initialize alg_key_len for IPComp states pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name: \tx->calg = kmalloc_obj(*x->calg); \tif (!x->calg) { \t\terr = -ENOMEM; \t\tgoto out; \t} \tstrcpy(x->calg->alg_name, a->name); \tx->props.calgo = sa->sadb_sa_encrypt; Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data. calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE: \txfrm_state_migrate() \t xfrm_state_clone_and_setup() \t x->calg = xfrm_algo_clone(orig->calg); \t kmemdup(orig, xfrm_alg_len(orig)); where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0): BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 ____sys_sendmsg+0x9f7/0xb90 ___sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4) Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail. The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent. Initialize calg->alg_key_len to 0, matching the aalg/ealg branches.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64599", "url": "https://ubuntu.com/security/CVE-2026-64599", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: amlogic - avoid double cleanup in meson_crypto_probe() When meson_allocate_chanlist() fails after a partial allocation, it already unwinds the allocated chanlist state through its local error path. meson_crypto_probe() then jump to error_flow and calls meson_free_chanlist() again, causing the same per-flow resources to be torn down twice. In the reproduced failure path, the second teardown re-entered crypto_engine_exit() on an already destroyed worker and KASAN reported a slab-use-after-free in kthread_destroy_worker(). Prevent double-free by handling partial allocation failures locally within meson_allocate_chanlist() and skipping the outer cleanup path. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. The bug was reproduced in a QEMU x86_64 guest booted with KASAN on v7.1, using the reproducer under tools/testing/meson_crypto_probe. The reproducer forces the second dma_alloc_attrs() call in the gxl-crypto probe path to return NULL, making meson_allocate_chanlist() fail after partial initialization. On the unpatched kernel this reliably triggered a slab-use-after-free. With this fix applied, the same reproducer no longer emits any KASAN report and the probe fails cleanly with -ENOMEM. ================================================================== BUG: KASAN: slab-use-after-free in kthread_destroy_worker+0xb2/0xd0 Read of size 8 at addr ff1100010c057a68 by task insmod/265 CPU: 1 UID: 0 PID: 265 Comm: insmod Tainted: G O 7.1.0-rc2-00376-g810af9adc907-dirty #10 PREEMPT(lazy) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcb/0x5e0 ? __virt_addr_valid+0x21d/0x3f0 ? kthread_destroy_worker+0xb2/0xd0 ? kthread_destroy_worker+0xb2/0xd0 kasan_report+0xca/0x100 ? kthread_destroy_worker+0xb2/0xd0 kthread_destroy_worker+0xb2/0xd0 meson_crypto_probe+0x4d0/0xc10 [amlogic_gxl_crypto] platform_probe+0x99/0x140 really_probe+0x1c6/0x6a0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x248/0x310 ? acpi_driver_match_device+0xb0/0x100 driver_probe_device+0x48/0x210 ? __pfx___device_attach_driver+0x10/0x10 __device_attach_driver+0x160/0x320 bus_for_each_drv+0x104/0x190 ? __pfx_bus_for_each_drv+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 __device_attach+0x19d/0x3b0 ? __pfx___device_attach+0x10/0x10 ? do_raw_spin_unlock+0x53/0x220 device_initial_probe+0x78/0xa0 bus_probe_device+0x5b/0x130 device_add+0xcfd/0x1430 ? __pfx_device_add+0x10/0x10 ? insert_resource+0x34/0x50 ? lock_release+0xc9/0x290 platform_device_add+0x24e/0x590 ? __pfx_meson_crypto_probe_repro_init+0x10/0x10 [meson_crypto_probe_repro] meson_crypto_probe_repro_init+0x330/0xff0 [meson_crypto_probe_repro] do_one_initcall+0xc0/0x450 ? __pfx_do_one_initcall+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x2c/0x50 ? __create_object+0x59/0x80 ? kasan_unpoison+0x27/0x60 do_init_module+0x27b/0x7d0 ? __pfx_do_init_module+0x10/0x10 ? kasan_quarantine_put+0x84/0x1d0 ? kfree+0x32c/0x510 ? load_module+0x561e/0x5ff0 load_module+0x54fe/0x5ff0 ? __pfx_load_module+0x10/0x10 ? security_file_permission+0x20/0x40 ? kernel_read_file+0x23d/0x6e0 ? mmap_region+0x235/0x4a0 ? __pfx_kernel_read_file+0x10/0x10 ? __file_has_perm+0x2c0/0x3e0 init_module_from_file+0x158/0x180 ? __pfx_init_module_from_file+0x10/0x10 ? __lock_acquire+0x45a/0x1ba0 ? idempotent_init_module+0x315/0x610 ? lock_release+0xc9/0x290 ? lock ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64440", "url": "https://ubuntu.com/security/CVE-2026-64440", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB write in HT_caps_handler() HT_caps_handler() iterates pIE->length bytes and writes into HT_caps.u.HT_cap[], which is a fixed 26-byte array (sizeof struct HT_caps_element). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlme_ext_info. Truncate the iteration count to the size of HT_caps.u.HT_cap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HT_caps_enable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64536", "url": "https://ubuntu.com/security/CVE-2026-64536", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop The loop in is_ap_in_tkip() iterates over IEs without verifying that enough bytes remain before dereferencing the IE header or its payload: - pIE->element_id and pIE->length are read without checking that i + sizeof(*pIE) <= ie_length, so a truncated IE at the end of the buffer causes an OOB read. - For WLAN_EID_VENDOR_SPECIFIC the code compares pIE->data + 12, which requires pIE->length >= 16. For WLAN_EID_RSN it compares pIE->data + 8, requiring pIE->length >= 12. Neither requirement is checked. Add the missing IE header and payload bounds checks and guard each data access with an explicit pIE->length minimum, matching the pattern established in update_beacon_info().", "cve_priority": "medium", "cve_public_date": "2026-07-27 08:16:00 UTC" }, { "cve": "CVE-2026-64442", "url": "https://ubuntu.com/security/CVE-2026-64442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl() Two IE parsing loops are missing the header bounds checks before they dereference pIE->length: - issue_assocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an element_id byte and no length byte, pIE->length is read one byte past the end of the buffer. - join_cmd_hdl() walks pnetwork->ies during station join and has the same problem under the same conditions. Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue. Apply the two-guard pattern established in update_beacon_info(): 1. Break if fewer than sizeof(*pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end.", "cve_priority": "high", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64443", "url": "https://ubuntu.com/security/CVE-2026-64443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop The IE parsing loop in update_beacon_info() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the element_id byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len. Also replace i += (pIE->length + 2) with i += sizeof(*pIE) + pIE->length for consistency with the sizeof(*pIE) guards added above.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64444", "url": "https://ubuntu.com/security/CVE-2026-64444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i < pkt_len. When a malicious AP sends an AssocResponse whose last IE has only one byte remaining in the frame (the element_id byte lands at pkt_len-1), the loop reads pIE->length from pframe[pkt_len], which is one byte past the allocated receive buffer. Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pkt_len, silently passing a truncated IE to the handler functions. Add two guards at the top of the loop body: 1. Break if fewer than sizeof(*pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pkt_len.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64445", "url": "https://ubuntu.com/security/CVE-2026-64445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth() OnAuth() has two bugs in the shared-key authentication path. When the Privacy bit is set, rtw_wep_decrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtw_wep_decrypt(), length is computed as: length = len - WLAN_HDR_A3_LEN - iv_len and then passed as (length - 4) to crc32_le(). If len is less than WLAN_HDR_A3_LEN + iv_len + icv_len (32 bytes), length - 4 is negative and, after the implicit cast to size_t, causes crc32_le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path. When processing a seq=3 response, rtw_get_ie() stores the Challenge Text IE length in ie_len, but the subsequent memcmp() always reads 128 bytes regardless of ie_len. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64450", "url": "https://ubuntu.com/security/CVE-2026-64450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it (\"if (glen > dlen) break;\"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: \tthis_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), \t\t\t GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: \"if (glen > dlen) break;\" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means \"legacy peer without Selective ACK\", a distinct legitimate state.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64452", "url": "https://ubuntu.com/security/CVE-2026-64452", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix NHC entry use-after-free on error path lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding lowpan_nhc_lock. If the descriptor has no uncompress callback, the error path drops the lock before printing nhc->name. lowpan_nhc_del() removes descriptors under the same lock and then relies on synchronize_net() before the owning module can be unloaded. That only waits for net RX RCU readers. lowpan_header_decompress() is also exported and can be reached from callers that are not necessarily covered by the net core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive path. This leaves a race where one task drops lowpan_nhc_lock in the error path, another task unregisters and frees the matching descriptor after synchronize_net() returns, and the first task then dereferences nhc->name for the warning. With the post-unlock window widened, KASAN reports: BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220 Read of size 8 lowpan_nhc_do_uncompression lowpan_header_decompress Fix this by printing the warning before dropping lowpan_nhc_lock, so the descriptor name is read while unregister is still excluded. The malformed packet is still rejected with -ENOTSUPP.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64454", "url": "https://ubuntu.com/security/CVE-2026-64454", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: run gadget disconnect from sleepable suspend context dwc3_gadget_suspend() takes dwc->lock with IRQs disabled and then calls dwc3_disconnect_gadget(). For async callbacks that helper only uses plain spin_unlock()/spin_lock(), so the gadget ->disconnect() callback still runs with IRQs disabled and any sleepable callback trips Lockdep. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the dwc3_gadget_suspend() -> dwc3_disconnect_gadget() -> gadget_driver->disconnect() chain, and Lockdep reported: BUG: sleeping function called from invalid context gadget_disconnect+0x21/0x39 [vuln_msv] dwc3_gadget_suspend.constprop.0+0x2b/0x42 [vuln_msv] Keep the disconnect callback selection in one common helper, but add a sleepable suspend-side wrapper which snapshots the callback under dwc->lock and then runs it after spin_unlock_irqrestore(). The regular event path still uses the existing spin_unlock()/spin_lock() window.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64455", "url": "https://ubuntu.com/security/CVE-2026-64455", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: chaoskey: Fix slab-use-after-free in chaoskey_release() The chaoskey driver has a use-after-free bug in its release routine. If the user closes the device file after the USB device has been unplugged, a debugging log statement will try to access the usb_interface structure after it has been deallocated: \tBUG: KASAN: slab-use-after-free in dev_driver_string (drivers/base/core.c:2406) \tRead of size 8 at addr ffff888168e8a0b8 by task chaoskey_raw_re/10106 \tHardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 \tCall Trace: \t \t dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) \t print_report (mm/kasan/report.c:378 mm/kasan/report.c:482) \t kasan_report (mm/kasan/report.c:595) \t dev_driver_string (drivers/base/core.c:2406) \t __dynamic_dev_dbg (lib/dynamic_debug.c:906) \t chaoskey_release (drivers/usb/misc/chaoskey.c:323) \t __fput (fs/file_table.c:510) \t fput_close_sync (fs/file_table.c:615) \t __x64_sys_close (fs/open.c:1507 fs/open.c:1492 fs/open.c:1492) \t do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) \t entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The driver's last reference to the interface structure is dropped in the chaoskey_free() routine, so the code must not use the interface -- even in a debugging statement -- after that routine returns. (Exception: If we know that another reference is held by someone else, such as the device core while the disconnect routine runs, there's no problem. Thanks to Johan Hovold for pointing this out.) Since the bad access is part of an unimportant debugging statement, we can fix the problem simply by removing the whole statement.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64456", "url": "https://ubuntu.com/security/CVE-2026-64456", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwrng: virtio: clamp device-reported used.len at copy_data() random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 (\"net/9p: Fix buffer overflow in USB transport layer\"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64189", "url": "https://ubuntu.com/security/CVE-2026-64189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64465", "url": "https://ubuntu.com/security/CVE-2026-64465", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix sleep in atomic context in xhci_free_streams() When a USB device with active stream endpoints is disconnected, xhci_free_streams() is called from the hub_event workqueue to free the stream resources. It calls xhci_free_stream_info() while holding xhci->lock with irqs disabled. xhci_free_stream_info() invokes xhci_free_stream_ctx(), which calls dma_free_coherent() for large stream context arrays. dma_free_coherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context. Call trace: dma_free_attrs+0x174/0x220 xhci_free_stream_info+0xd0/0x11c xhci_free_streams+0x278/0x37c usb_free_streams+0x98/0xc0 usb_unbind_interface+0x1b8/0x2f8 device_release_driver_internal+0x1d4/0x2cc device_release_driver+0x18/0x28 bus_remove_device+0x160/0x1a4 device_del+0x1ec/0x350 usb_disable_device+0x98/0x214 usb_disconnect+0xf0/0x35c hub_event+0xab4/0x19ec process_one_work+0x278/0x63c Fix this by saving the stream_info pointers and clearing the ep references under the lock, then calling xhci_free_stream_info() outside the lock where sleeping is allowed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64468", "url": "https://ubuntu.com/security/CVE-2026-64468", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_free_transaction() In binder_free_transaction(), the t->to_proc is read under the t->lock. However, once the t->lock is dropped, the to_proc can die in parallel. This leads to a use-after-free error when we attempt to acquire its inner lock right afterwards: ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x1a0 Write of size 4 at addr ffff00001125da70 by task B/672 CPU: 20 UID: 0 PID: 672 Comm: B Not tainted 7.1.0-rc6-00284-g8e65320d91cd #4 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x1a0 binder_free_transaction+0x8c/0x320 binder_send_failed_reply+0x21c/0x2f8 binder_thread_release+0x488/0x7e0 binder_ioctl+0x12c0/0x29a0 [...] Allocated by task 675: __kmalloc_cache_noprof+0x174/0x444 binder_open+0x118/0xb70 do_dentry_open+0x374/0x1040 vfs_open+0x58/0x3bc [...] Freed by task 212: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_proc_dec_tmpref+0x32c/0x5e0 binder_deferred_func+0xc48/0x104c process_one_work+0x53c/0xbc0 [...] ================================================================== To prevent this, pin the target thread (t->to_thread) to guarantee the target process remains alive. Undelivered transactions without a target thread are already safe, as the target process can only be the current context in those paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64469", "url": "https://ubuntu.com/security/CVE-2026-64469", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_thread_release() When a thread exits, binder_thread_release() walks its transaction stack to clear the t->from and t->to_proc that correspond with the exiting thread. However, a process dying in parallel might attempt to kfree some of these transactions. And if one of them has no associated t->to_proc, the t->to_proc->inner_lock will not be acquired. This means that transaction accesses in binder_thread_release() after t->to_proc has been cleared might race with binder_free_transaction() and cause a use-after-free error as reported by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798 Write of size 8 at addr ffff000016627500 by task X/715 CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...] Allocated by task 717 on cpu 18 at 67.267803s: __kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+0x554/0x8150 binder_thread_write+0xa30/0x4354 binder_ioctl+0x20f0/0x299c [...] Freed by task 202 on cpu 18 at 90.416221s: __kasan_slab_free+0x58/0x80 kfree+0x1a0/0x4a4 binder_free_transaction+0x150/0x294 binder_send_failed_reply+0x398/0x6d8 binder_release_work+0x3e4/0x4ec binder_deferred_func+0xbd8/0x104c [...] ================================================================== In order to avoid this, make sure that binder_free_transaction() reads the t->to_proc under the transaction lock. This will serialize the transaction release with the accesses in binder_thread_release(). Plus, it matches the documented locking rules for @to_proc.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64470", "url": "https://ubuntu.com/security/CVE-2026-64470", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on marvell probe failure Make sure to stop any TX URBs submitted during Marvell OOB wakeup configuration on later probe failures to avoid use-after-free in the completion callback. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64471", "url": "https://ubuntu.com/security/CVE-2026-64471", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: fix use-after-free on registration failure Make sure to release the sibling interfaces in case controller registration fails to avoid use-after-free and double-free when they are eventually disconnected. This issue was reported by Sashiko while reviewing a fix for a wakeup source leak in the btusb probe errors paths.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64478", "url": "https://ubuntu.com/security/CVE-2026-64478", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: avoid kobject path lookup in DualSense match The DualSense jack-detection input handler verifies that a matching input device belongs to the same physical controller by building kobject path strings for both the input device and the USB audio device, then comparing the path prefix. This was observed when a weak physical connection caused the controller to rapidly disconnect and reconnect. During that repeated hotplug, snd_dualsense_ih_match() can run while the controller's USB device is being disconnected. kobject_get_path() walks ancestor kobjects and dereferences their names; if the USB device kobject name is no longer valid, this can fault in strlen(): RIP: 0010:strlen+0x10/0x30 Call Trace: kobject_get_path+0x34/0x150 snd_dualsense_ih_match+0x49/0xd0 [snd_usb_audio] input_register_device+0x566/0x6a0 ps_probe+0xb89/0x1590 [hid_playstation] The same ownership check can be done without building kobject path strings. The input device is parented below the HID device, USB interface and USB device, so walking the input device parent chain and comparing against the mixer USB device preserves the check without dereferencing kobject names during disconnect.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64483", "url": "https://ubuntu.com/security/CVE-2026-64483", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire: isight: bound the sample count to the packet payload isight_packet() takes the frame count from the device iso packet and checks it only against the device claimed iso length. \tcount = be32_to_cpu(payload->sample_count); \tif (likely(count <= (length - 16) / 4)) \t\tisight_samples(isight, payload->samples, count); length is the iso header data_length. It can be up to 0xffff. So the gate allows a count up to about 16379. isight_samples() then copies count frames out of payload->samples into the PCM DMA buffer. payload->samples holds only 2 * MAX_FRAMES_PER_PACKET values. The device multiplexes two samples per frame. A count past MAX_FRAMES_PER_PACKET reads past the payload. A count past the buffer size writes past runtime->dma_area. The smallest PCM buffer is larger than MAX_FRAMES_PER_PACKET. Bounding the count to MAX_FRAMES_PER_PACKET keeps both the read and the write in range. A malicious or faulty Apple iSight on the FireWire bus reaches this during a normal capture. Add the MAX_FRAMES_PER_PACKET bound to the gate.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64484", "url": "https://ubuntu.com/security/CVE-2026-64484", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: es1938: check snd_ctl_new1() return value snd_ctl_new1() can return NULL when memory allocation fails. snd_es1938_mixer() does not check the return value before dereferencing the pointer, which can lead to a NULL pointer dereference. Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64487", "url": "https://ubuntu.com/security/CVE-2026-64487", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every iteration it advances buf and subtracts the block size while looping on \"while (len)\". len is urb->actual_length. That value is supplied by the device and is not guaranteed to be a multiple of 16. When a final short block leaves len between 1 and 15, the loop runs once more, reads up to buf[15], and then does \"len -= TKS4_MSGBLOCK_SIZE\". As len is unsigned this underflows to a huge value. The loop then keeps iterating and walking buf far past the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus block id happens to be hit. Iterate only while a full message block is available. This stops the unsigned underflow and silently drops any trailing partial block, which carries no complete control value anyway. The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1 and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor urb->actual_length before dispatching.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64494", "url": "https://ubuntu.com/security/CVE-2026-64494", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: gp2ap002: fix runtime PM leak on read error gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the lux value, but if gp2ap002_get_lux() fails, it returns directly. This skips the pm_runtime_put_autosuspend() call at the \"out\" label, permanently leaking a runtime PM reference and preventing the device from autosuspending. Replace the direct return with a \"goto out\" to ensure the reference is properly dropped on the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64495", "url": "https://ubuntu.com/security/CVE-2026-64495", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gyro: bmg160: bail out when bandwidth/filter is not in table bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry matching the bw_bits value read from the chip: \tfor (i = 0; i < ARRAY_SIZE(bmg160_samp_freq_table); ++i) { \t\tif (bmg160_samp_freq_table[i].bw_bits == bw_bits) \t\t\tbreak; \t} \t*val = bmg160_samp_freq_table[i].filter; If no entry matches, i ends up equal to the array size and the next line reads one slot past the end. bmg160_set_filter() has the same shape, driven by 'val' instead of bw_bits. smatch flags both: drivers/iio/gyro/bmg160_core.c:204 bmg160_get_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 drivers/iio/gyro/bmg160_core.c:222 bmg160_set_filter() error: buffer overflow 'bmg160_samp_freq_table' 7 <= 7 Return -EINVAL when no entry matches. The set_filter() path is reachable from userspace via the sysfs in_anglvel_filter_low_pass_3db_frequency interface, so userspace can trivially trigger the out-of-bounds read with a value that is not in bmg160_samp_freq_table[].filter.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64496", "url": "https://ubuntu.com/security/CVE-2026-64496", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64497", "url": "https://ubuntu.com/security/CVE-2026-64497", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: chemical: scd30: Cleanup initializations and fix sign-extension bug Include linux/bitfield.h for FIELD_GET(). Create new macros for bit manipulation in combination with manual bit manipulation being replaced with FIELD_GET(). The current variable declaration and initializations are barely readable and use comma separations across multiple lines. Refactor the initializations so that mantissa and exp have separate declarations and sign gets initialized later. In addition (and due to the nature of the cleanup), fix a sign-extension bug where, float32 would get bitwise anded with ~BIT(31) (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64602", "url": "https://ubuntu.com/security/CVE-2026-64602", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: spear: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"spear_adc_probe() in drivers/iio/adc/spear_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in spear_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, spear_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ spear_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-64500", "url": "https://ubuntu.com/security/CVE-2026-64500", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: lpc32xx: Initialize completion before requesting IRQ In the report from Jaeyoung Chung: \"lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its interrupt handler with devm_request_irq() before it initializes st->completion with init_completion(). If an interrupt arrives after devm_request_irq() and before init_completion(), the handler calls complete() on an uninitialized completion, causing a kernel panic. The probe path, in lpc32xx_adc_probe(): iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */ ... retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0, LPC32XXAD_NAME, st); /* register handler */ ... init_completion(&st->completion); /* initialize completion */ lpc32xx_adc_isr() calls complete(): complete(&st->completion); If the device raises an interrupt before init_completion() runs, complete() acquires the uninitialized wait.lock and walks the zeroed task_list in swake_up_locked(). The zeroed task_list makes list_empty() return false, so swake_up_locked() dereferences a NULL list entry, triggering a KASAN wild-memory-access.\" Fix the chance of a spurious IRQ causing an uninitialized pointer dereference by moving init_completion() above devm_request_irq().", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64503", "url": "https://ubuntu.com/security/CVE-2026-64503", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error kxsd9_write_raw() takes a runtime PM reference with pm_runtime_get_sync() but returns -EINVAL directly when a scale with a non-zero integer part is requested, skipping the matching pm_runtime_put_autosuspend(). This leaks a runtime PM usage-counter reference on every such write, after which the device can no longer autosuspend. Set the error code and fall through to the existing put instead of returning early.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64504", "url": "https://ubuntu.com/security/CVE-2026-64504", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: accel: bmc150: clamp the device-reported FIFO frame count __bmc150_accel_fifo_flush() copies the number of samples the device reports in its hardware FIFO into an on-stack buffer \tu16 buffer[BMC150_ACCEL_FIFO_LENGTH * 3]; which is sized for at most BMC150_ACCEL_FIFO_LENGTH (32) samples. The frame count is read from the FIFO_STATUS register and only masked to its 7 valid bits: \tcount = val & 0x7F; so it can be 0..127. The only other limit applied to it is the optional caller-supplied sample budget: \tif (samples && count > samples) \t\tcount = samples; which does not constrain count on the flush-all path (samples == 0), and leaves it well above 32 whenever samples is larger. count samples are then transferred into buffer[]: \tbmc150_accel_fifo_transfer(data, (u8 *)buffer, count); bmc150_accel_fifo_transfer() reads count * 6 bytes through regmap, so a malfunctioning, malicious or counterfeit accelerometer (or an attacker tampering with the I2C/SPI bus) that reports up to 127 frames writes up to 762 bytes into the 192-byte buffer: a stack out-of-bounds write of up to 570 bytes that clobbers the stack canary, saved registers and the return address. Clamp count to BMC150_ACCEL_FIFO_LENGTH, the number of samples buffer[] is sized for, before the transfer, mirroring the watermark clamp already done in bmc150_accel_set_watermark(). A well-formed flush reports at most BMC150_ACCEL_FIFO_LENGTH frames, so legitimate devices are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-64505", "url": "https://ubuntu.com/security/CVE-2026-64505", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check for header Add a length check for the rndis header in rndis_rm_hdr, to ensure that MessageType, MessageLength, DataOffset, and DataLength fields are present before they are accessed.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68088", "url": "https://ubuntu.com/security/CVE-2026-68088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: function: rndis: add length check to response query Add variable representations for BufLength and BufOffset in rndis_query_response(), and perform a length check on them. This is identical to how rndis_set_response() handles these parameters.", "cve_priority": "medium", "cve_public_date": "2026-08-10 12:17:00 UTC" }, { "cve": "CVE-2026-53392", "url": "https://ubuntu.com/security/CVE-2026-53392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53402", "url": "https://ubuntu.com/security/CVE-2026-53402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font() When fbcon_do_set_font() fails (e.g., due to a memory allocation failure inside vc_resize() under heavy memory pressure), it jumps to the `err_out` label to roll back the console state. However, the current rollback logic forgets to restore the `hi_font` state, leading to a severe state machine corruption. Earlier in the function, `set_vc_hi_font()` might be called to change `vc->vc_hi_font_mask` and mutate the screen buffer. If `vc_resize()` subsequently fails, the `err_out` path restores `vc_font.charcount` but entirely skips rolling back the `vc_hi_font_mask` and the screen buffer. This mismatch leaves the terminal in a desynchronized state. Because `vc_hi_font_mask` remains set, the VT subsystem will still accept character indices greater than 255 from userspace and write them to the screen buffer. Subsequent rendering calls (e.g., `fbcon_putcs()`) will then use these inflated indices to access the reverted, 256-character font array, leading to a deterministic out-of-bounds read and potential kernel memory disclosure. Fix this by adding the missing rollback logic for the `hi_font` mask and screen buffer in the error path.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63810", "url": "https://ubuntu.com/security/CVE-2026-63810", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: Avoid mounting the bdev pseudo-filesystem in userspace The bdev pseudo-filesystem is an internal kernel filesystem with which userspace should not interfere. Unregister it so that userspace cannot even attempt to mount it. This fixes a bug [1] that occurs when attempting to access files, because the system call move_mount() uses pointers declared in the inode_operations structure, which for the bdev pseudo-filesystem are always equal to 0. `inode->i_op = &empty_iops;` [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 23380067 P4D 23380067 PUD 23381067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 PID: 17125 Comm: syz-executor.0 Not tainted 6.1.155-syzkaller-00350-g84221fde2681 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:0x0 Call Trace: lookup_open.isra.0+0x700/0x1180 fs/namei.c:3460 open_last_lookups fs/namei.c:3550 [inline] path_openat+0x953/0x2700 fs/namei.c:3780 do_filp_open+0x1c5/0x410 fs/namei.c:3810 do_sys_openat2+0x171/0x4d0 fs/open.c:1318 do_sys_open fs/open.c:1334 [inline] __do_sys_openat fs/open.c:1350 [inline] __se_sys_openat fs/open.c:1345 [inline] __x64_sys_openat+0x13c/0x1f0 fs/open.c:1345 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Found by Linux Verification Center (linuxtesting.org) with Syzkaller.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68459", "url": "https://ubuntu.com/security/CVE-2026-68459", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs() When we mount device w/ gc_merge mount option, we may suffer below potential deadlock: Kworker\t\t\t\t\tGC trehad\t\t\tTruncator - f2fs_write_cache_pages - f2fs_write_single_data_page - f2fs_do_write_data_page - folio_start_writeback --- set writeback flag on folio - f2fs_outplace_write_data : cached folio in internal bio cache - f2fs_balance_fs - wake_up(gc_thread) : wake up gc thread to run foreground GC - finish_wait(fggc_wq) : wait on the waitqueue --- wait on GC thread to finish the work \t\t\t\t\t\t\t\t\t- truncate_inode_pages_range \t\t\t\t\t\t\t\t\t - __filemap_get_folio(, FGP_LOCK) --- lock folio \t\t\t\t\t\t\t\t\t - truncate_inode_partial_folio \t\t\t\t\t\t\t\t\t - folio_wait_writeback --- wait on writeback being cleared \t\t\t\t\t- do_garbage_collect \t\t\t\t\t - move_data_page \t\t\t\t\t - f2fs_get_lock_data_folio \t\t\t\t\t - lock on folio --- blocked on folio's lock In order to avoid such deadlock, let's call below functions to commit cached bios in GC_MERGE path of f2fs_balance_fs() as the same as we did in NOGC_MERGE path. - f2fs_submit_merged_write(sbi, DATA); - f2fs_submit_all_merged_ipu_writes(sbi);", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-68460", "url": "https://ubuntu.com/security/CVE-2026-68460", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix potential deadlock in f2fs_balance_fs() When the f2fs filesystem space is nearly exhausted, we encounter deadlock issues as below: INFO: task A:1890 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:A state:D stack:0 pid:1890 tgid:1626 ppid:1153 flags:0x00000204 Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 folio_wait_bit+0x20/0x38 folio_wait_writeback+0x54/0xc8 truncate_inode_partial_folio+0x70/0x1e0 truncate_inode_pages_range+0x1b0/0x450 truncate_pagecache+0x54/0x88 f2fs_file_write_iter+0x3e8/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task kworker/u8:11:2680853 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:11 state:D stack:0 pid:2680853 tgid:2680853 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 schedule+0x3c/0x118 io_schedule+0x44/0x68 folio_wait_bit_common+0x174/0x370 __filemap_get_folio+0x214/0x348 pagecache_get_page+0x20/0x70 f2fs_get_read_data_page+0x150/0x3e8 f2fs_get_lock_data_page+0x2c/0x160 move_data_page+0x50/0x478 do_garbage_collect+0xd38/0x1528 f2fs_gc+0x240/0x7e0 f2fs_balance_fs+0x1a0/0x208 f2fs_write_single_data_page+0x6e4/0x730 f2fs_write_cache_pages+0x378/0x9b0 f2fs_write_data_pages+0x2e4/0x388 do_writepages+0x8c/0x2c8 __writeback_single_inode+0x4c/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x200 INFO: task kworker/u8:8:2641297 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:kworker/u8:8 state:D stack:0 pid:2641297 tgid:2641297 ppid:2 flags:0x00000208 Workqueue: writeback wb_workfn (flush-254:0) Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_write_inode+0xf4/0x328 __writeback_single_inode+0x370/0x498 writeback_sb_inodes+0x234/0x4a8 __writeback_inodes_wb+0x58/0x118 wb_writeback+0x2f8/0x3c0 wb_workfn+0x2c4/0x508 process_one_work+0x180/0x408 worker_thread+0x258/0x368 kthread+0x118/0x128 ret_from_fork+0x10/0x20 INFO: task B:1902 blocked for more than 120 seconds. Tainted: G O 6.12.41-g3fe07ddf05ab #1 \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message. task:B state:D stack:0 pid:1902 tgid:1626 ppid:1153 flags:0x0000020c Call trace: __switch_to+0xf4/0x158 __schedule+0x27c/0x908 rt_mutex_schedule+0x30/0x60 __rt_mutex_slowlock_locked.constprop.0+0x460/0x8a8 rwbase_write_lock+0x24c/0x378 down_write+0x1c/0x30 f2fs_balance_fs+0x184/0x208 f2fs_map_blocks+0x94c/0x1110 f2fs_file_write_iter+0x228/0xb80 do_iter_readv_writev+0xf0/0x1e0 vfs_writev+0x138/0x2c8 do_writev+0x88/0x130 __arm64_sys_writev+0x28/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x30/0xf8 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x190/0x198 INFO: task sync:2769849 blocked for more than 120 seconds. Tainted: G ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63815", "url": "https://ubuntu.com/security/CVE-2026-63815", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: bound i_inline_xattr_size for non-inline-xattr inodes When the flexible_inline_xattr feature is enabled, do_read_inode() loads the on-disk i_inline_xattr_size unconditionally: \tif (f2fs_sb_has_flexible_inline_xattr(sbi)) \t\tfi->i_inline_xattr_size = le16_to_cpu(ri->i_inline_xattr_size); but sanity_check_inode() only range-checks it when the inode also has the FI_INLINE_XATTR flag set. An inode that carries an inline dentry or inline data but not FI_INLINE_XATTR -- the normal layout for an inline directory -- therefore keeps a fully attacker-controlled i_inline_xattr_size from a crafted image. get_inline_xattr_addrs() returns that value with no flag gating, so it feeds the inode geometry: \tMAX_INLINE_DATA() = 4 * (CUR_ADDRS_PER_INODE - i_inline_xattr_size - 1) \tNR_INLINE_DENTRY() = MAX_INLINE_DATA() * BITS_PER_BYTE / (...) \taddrs_per_page() = CUR_ADDRS_PER_INODE - i_inline_xattr_size A large i_inline_xattr_size drives MAX_INLINE_DATA() and NR_INLINE_DENTRY() negative, so make_dentry_ptr_inline() sets d->max (int) to a negative value. The inline directory walk then compares an unsigned long bit_pos against that negative d->max, which is promoted to a huge unsigned bound, and reads far past the inline area: \twhile (bit_pos < d->max)\t\t/* fs/f2fs/dir.c */ \t\t... test_bit_le(bit_pos, d->bitmap) / d->dentry[bit_pos] ... Mounting a crafted image and reading such a directory triggers an out-of-bounds read in f2fs_fill_dentries(); the same underflow also corrupts ADDRS_PER_INODE for regular files. Validate i_inline_xattr_size against MAX_INLINE_XATTR_SIZE whenever the flexible_inline_xattr feature is enabled -- i.e. whenever the value is loaded from disk and consumed -- and keep the lower MIN_INLINE_XATTR_SIZE bound gated on inodes that actually carry an inline xattr, so legitimate inodes with i_inline_xattr_size == 0 are still accepted.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63818", "url": "https://ubuntu.com/security/CVE-2026-63818", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate orphan inode entry count f2fs_recover_orphan_inodes() trusts the orphan block entry_count when replaying orphan inodes from the checkpoint pack. A corrupted entry_count larger than F2FS_ORPHANS_PER_BLOCK makes the recovery loop read past the ino[] array and interpret footer or following data as inode numbers. On a crafted image, mounting an unpatched kernel can drive orphan recovery into f2fs_bug_on() and panic the kernel. Validate entry_count before consuming entries so corrupted checkpoint data fails the mount with -EFSCORRUPTED and requests fsck instead. Set ERROR_INCONSISTENT_ORPHAN as well, so the corruption reason can be recorded in the superblock s_errors[] field. This gives fsck a persistent hint even though mount-time orphan recovery failure may leave no chance to persist SBI_NEED_FSCK through a checkpoint.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-68461", "url": "https://ubuntu.com/security/CVE-2026-68461", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device property: initialize the remaining fields of fwnode_handle in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitialized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. While at it: initialize the remaining fields of struct fwnode_handle too just to be sure. [ Fix typo in commit message. - Danilo ]", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:18:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63829", "url": "https://ubuntu.com/security/CVE-2026-63829", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper. Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs. Commit 8b484efd5cb4 (\"ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\") added the same check on the ioctl path. This adds it on RTM_NEWLINK.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53332", "url": "https://ubuntu.com/security/CVE-2026-53332", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd When the remoteproc starts in parallel with the NGD driver being probed, or the remoteproc is already up when the PDR lookup is being registered, or in the theoretical event that we get an interrupt from the hardware, these callbacks will operate on uninitialized data. This result in issues to boot the affected boards. One such example can be seen in the following fault, where qcom_slim_ngd_ssr_pdr_notify() schedules work on the NULL ngd_up_work. [ 21.858578] ------------[ cut here ]------------ [ 21.858745] WARNING: kernel/workqueue.c:2338 at __queue_work+0x5e0/0x790, CPU#2: kworker/2:2/116 ... [ 21.859251] Call trace: [ 21.859255] __queue_work+0x5e0/0x790 (P) [ 21.859265] queue_work_on+0x6c/0xf0 [ 21.859273] qcom_slim_ngd_ssr_pdr_notify+0x110/0x150 [slim_qcom_ngd_ctrl] [ 21.859304] qcom_slim_ngd_ssr_notify+0x24/0x40 [slim_qcom_ngd_ctrl] [ 21.859318] notifier_call_chain+0xa4/0x230 [ 21.859329] srcu_notifier_call_chain+0x64/0xb8 [ 21.859338] ssr_notify_start+0x40/0x78 [qcom_common] [ 21.859355] rproc_start+0x130/0x230 [ 21.859367] rproc_boot+0x3d4/0x518 ... Move the enablement of interrupts, and the registration of SSR and PDR until after the NGD device has been registered. This could be further refined by moving initialization to the control driver probe and by removing the platform driver model from the picture.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2022-3114", "url": "https://ubuntu.com/security/CVE-2022-3114", "cve_description": "An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference.", "cve_priority": "negligible", "cve_public_date": "2022-12-14 21:15:00 UTC" }, { "cve": "CVE-2026-64514", "url": "https://ubuntu.com/security/CVE-2026-64514", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: userfaultfd: gate must_wait writability check on pte_present() userfaultfd_must_wait() and userfaultfd_huge_must_wait() read the PTE without taking the page table lock and then apply pte_write() / huge_pte_write() to it. Those accessors decode bits from the present encoding only; on a swap or migration entry they read the offset bits that happen to share the same position and return an undefined result. The intent of the check is \"is this fault still WP-blocked?\". A non-marker swap entry means the page is in transit -- the userfault context the original fault delivered against is no longer the same, and the swap-in or migration completion path will re-deliver a fresh fault if userspace still needs to handle it. Worst case under the current code the garbage write bit says \"wait\", and the thread stays asleep until a UFFDIO_WAKE that may never arrive. Gate the writability check on pte_present() so the lockless re-check only inspects present-PTE bits when the entry is actually present. The non-present, non-marker case returns \"don't wait\" and lets the fault path retry.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53399", "url": "https://ubuntu.com/security/CVE-2026-53399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: release layout stid on setlease failure nfs4_alloc_stid() publishes the new stid into cl->cl_stateids via idr_alloc_cyclic() under cl_lock before returning to nfsd4_alloc_layout_stateid(). When nfsd4_layout_setlease() then fails, the error path frees the layout stateid directly with kmem_cache_free() without ever calling idr_remove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer. The correct teardown for an IDR-published stid is nfs4_put_stid(), which removes the IDR slot under cl_lock, dispatches sc_free (nfsd4_free_layout_stateid) to release ls->ls_file via nfsd4_close_layout(), and drops the nfs4_file reference in its tail. A second issue blocks that switch: nfsd4_free_layout_stateid() unconditionally inspects ls->ls_fence_work via delayed_work_pending() under ls_lock, but INIT_DELAYED_WORK(&ls->ls_fence_work, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work. nfsd4_alloc_layout_stateid() nfs4_alloc_stid() /* idr_alloc_cyclic under cl_lock */ nfsd4_layout_setlease() /* fails */ nfs4_put_stid() nfsd4_free_layout_stateid() delayed_work_pending(&ls->ls_fence_work) /* needs INIT */ nfsd4_close_layout() /* nfsd_file_put(ls->ls_file) */ put_nfs4_file() Fix by hoisting the ls_fenced / ls_fence_delay / INIT_DELAYED_WORK initialization above the nfsd4_layout_setlease() call, and replace the manual nfsd_file_put + put_nfs4_file + kmem_cache_free cleanup with a single nfs4_put_stid(stp).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53158", "url": "https://ubuntu.com/security/CVE-2026-53158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix NULL pointer dereference in rpmsg callback A NULL pointer dereference was observed on Hawi at boot when the DSP sends a glink message before fastrpc_rpmsg_probe() has completed initialization: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000178 pc : _raw_spin_lock_irqsave+0x34/0x8c lr : fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] ... Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) fastrpc_rpmsg_callback+0x3c/0xcc [fastrpc] qcom_glink_native_rx+0x538/0x6a4 qcom_glink_smem_intr+0x14/0x24 [qcom_glink_smem] The faulting address 0x178 corresponds to the lock variable inside struct fastrpc_channel_ctx, confirming that cctx is NULL when fastrpc_rpmsg_callback() attempts to take the spinlock. There are two issues here. First, dev_set_drvdata() is called before spin_lock_init() and idr_init(), leaving a window where the callback can retrieve a valid cctx pointer but operate on an uninitialized spinlock. Second, the rpmsg channel becomes live as soon as the driver is bound, so fastrpc_rpmsg_callback() can fire before dev_set_drvdata() is called at all, resulting in dev_get_drvdata() returning NULL. Fix both issues by moving all cctx initialization ahead of dev_set_drvdata() so the structure is fully initialized before it becomes visible to the callback, and add a NULL check in fastrpc_rpmsg_callback() as a guard against any remaining window.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-39931", "url": "https://ubuntu.com/security/CVE-2025-39931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Set merge to zero early in af_alg_sendmsg If an error causes af_alg_sendmsg to abort, ctx->merge may contain a garbage value from the previous loop. This may then trigger a crash on the next entry into af_alg_sendmsg when it attempts to do a merge that can't be done. Fix this by setting ctx->merge to zero near the start of the loop.", "cve_priority": "high", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-31451", "url": "https://ubuntu.com/security/CVE-2026-31451", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio Replace BUG_ON() with proper error handling when inline data size exceeds PAGE_SIZE. This prevents kernel panic and allows the system to continue running while properly reporting the filesystem corruption. The error is logged via ext4_error_inode(), the buffer head is released to prevent memory leak, and -EFSCORRUPTED is returned to indicate filesystem corruption.", "cve_priority": "medium", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-43355", "url": "https://ubuntu.com/security/CVE-2026-43355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: bh1780: fix PM runtime leak on error path Move pm_runtime_put_autosuspend() before the error check to ensure the PM runtime reference count is always decremented after pm_runtime_get_sync(), regardless of whether the read operation succeeds or fails.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-53139", "url": "https://ubuntu.com/security/CVE-2026-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Skip CSD when it has zeroed workgroups A compute shader dispatch encodes its workgroup counts in the CFG0..CFG2 registers. Kicking off a dispatch with a zero count in any of the three dimensions is invalid. First, the hardware will process 0 as 65536, while the user-space driver exposes a maximum of 65535. Over that, a submission with a zeroed workgroup dimension should be a no-op. These zeroed counts can reach the dispatch path through an indirect CSD job, whose workgroup counts are only known once the indirect buffer is read and may legitimately be zero, but such scenario should only result in a no-op. Overwrite the indirect CSD job workgroup counts with the indirect BO ones, even if they are zeroed, and don't submit the job to the hardware when any of the workgroup counts is zero, so the job completes immediately instead of running the shader.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53138", "url": "https://ubuntu.com/security/CVE-2026-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;) and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since most are connector- based) 256 is a generous upper bound. (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-10263", "url": "https://ubuntu.com/security/CVE-2025-10263", "cve_description": "Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.", "cve_priority": "high", "cve_public_date": "2026-06-09 10:16:00 UTC" }, { "cve": "CVE-2026-31402", "url": "https://ubuntu.com/security/CVE-2026-31402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request.", "cve_priority": "critical", "cve_public_date": "2026-04-03 16:16:00 UTC" }, { "cve": "CVE-2026-23364", "url": "https://ubuntu.com/security/CVE-2026-23364", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Compare MACs in constant time To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, crypto_memneq().", "cve_priority": "medium", "cve_public_date": "2026-03-25 11:16:00 UTC" }, { "cve": "CVE-2026-43341", "url": "https://ubuntu.com/security/CVE-2026-43341", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. __ioam6_fill_trace_data() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer. Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.", "cve_priority": "high", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-46208", "url": "https://ubuntu.com/security/CVE-2026-46208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: stop tp_meter sessions during mesh teardown TP meter sessions remain linked on bat_priv->tp_list after the netlink request has already finished. When the mesh interface is removed, batadv_mesh_free() currently tears down the mesh without first draining these sessions. A running sender thread or a late incoming tp_meter packet can then keep processing against a mesh instance which is already shutting down. Synchronize tp_meter with the mesh lifetime by stopping all active sessions from batadv_mesh_free() and waiting for sender threads to exit before teardown continues.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2023-54271", "url": "https://ubuntu.com/security/CVE-2023-54271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init blk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This happens because iocg->ioc is NULL. The field is initialized by ioc_pd_init() and never cleared. The NULL deref is caused by blkcg_activate_policy() installing blkg_policy_data before initializing it. blkcg_activate_policy() was doing the following: 1. Allocate pd's for all existing blkg's and install them in blkg->pd[]. 2. Initialize all pd's. 3. Online all pd's. blkcg_activate_policy() only grabs the queue_lock and may release and re-acquire the lock as allocation may need to sleep. ioc_weight_write() grabs blkcg->lock and iterates all its blkg's. The two can race and if ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a pd which is not initialized yet, leading to crash. The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c \"echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos\" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weight with the following patch applied: > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index fc49be622e05..38d671d5e10c 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol) > \t\tpd->online = false; > \t} > > + if (system_state == SYSTEM_RUNNING) { > + spin_unlock_irq(&q->queue_lock); > + ssleep(1); > + spin_lock_irq(&q->queue_lock); > + } > + > \t/* all allocated, init in the same order */ > \tif (pol->pd_init_fn) > \t\tlist_for_each_entry_reverse(blkg, &q->blkg_list, q_node) I don't see a reason why all pd's should be allocated, initialized and onlined together. The only ordering requirement is that parent blkgs to be initialized and onlined before children, which is guaranteed from the walking order. Let's fix the bug by allocating, initializing and onlining pd for each blkg and holding blkcg->lock over initialization and onlining. This ensures that an installed blkg is always fully initialized and onlined removing the the race window.", "cve_priority": "medium", "cve_public_date": "2025-12-30 13:16:00 UTC" }, { "cve": "CVE-2026-45850", "url": "https://ubuntu.com/security/CVE-2026-45850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: skip ipv6 extension headers for csum checks Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2026-53189", "url": "https://ubuntu.com/security/CVE-2026-53189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: update file PMD counter before folio_put() __split_huge_pmd_locked() updates the file/shmem RSS counter after dropping the PMD mapping's folio reference. If folio_put() drops the last reference, mm_counter_file() can later read freed folio state via folio_test_swapbacked(). Move the counter update before folio_put().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53133", "url": "https://ubuntu.com/security/CVE-2026-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53199", "url": "https://ubuntu.com/security/CVE-2026-53199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 (\"hv_netvsc: Preserve contiguous PFN grouping in the page buffer array\"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53134", "url": "https://ubuntu.com/security/CVE-2026-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: fix stale stack leak via the OIFNAME register For NFT_FIB_RESULT_OIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one register via \"*dest = 0\". The remaining three registers are left as whatever was on the stack in nft_do_chain()'s struct nft_regs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace. The NFTA_FIB_F_PRESENT existence check has the same shape: it is only meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type while the eval stores a single byte via nft_reg_store8(), leaving the rest of the declared span stale. Fix both: - replace the bare \"*dest = 0\" in the eval with nft_fib_store_result(), which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52943", "url": "https://ubuntu.com/security/CVE-2026-52943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().", "cve_priority": "medium", "cve_public_date": "2026-06-24 10:17:00 UTC" }, { "cve": "CVE-2026-52918", "url": "https://ubuntu.com/security/CVE-2026-52918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46160", "url": "https://ubuntu.com/security/CVE-2026-46160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix missing last_unlink_trans update when removing a directory When removing a directory we are not updating its last_unlink_trans field, which can result in incorrect fsync behaviour in case some one fsyncs the directory after it was removed because it's holding a file descriptor on it. Example scenario: mkdir /mnt/dir1 mkdir /mnt/dir1/dir2 mkdir /mnt/dir3 sync -f /mnt # Do some change to the directory and fsync it. chmod 700 /mnt/dir1 xfs_io -c fsync /mnt/dir1 # Move dir2 out of dir1 so that dir1 becomes empty. mv /mnt/dir1/dir2 /mnt/dir3/ open fd on /mnt/dir1 call rmdir(2) on path \"/mnt/dir1\" fsync fd When attempting to mount the filesystem, the log replay will fail with an -EIO error and dmesg/syslog has the following: [445771.626482] BTRFS info (device dm-0): first mount of filesystem 0368bbea-6c5e-44b5-b409-09abe496e650 [445771.626486] BTRFS info (device dm-0): using crc32c checksum algorithm [445771.627912] BTRFS info (device dm-0): start tree-log replay [445771.628335] page: refcount:2 mapcount:0 mapping:0000000061443ddc index:0x1d00 pfn:0x7072a5 [445771.629453] memcg:ffff89f400351b00 [445771.629892] aops:btree_aops [btrfs] ino:1 [445771.630737] flags: 0x17fffc00000402a(uptodate|lru|private|writeback|node=0|zone=2|lastcpupid=0x1ffff) [445771.632359] raw: 017fffc00000402a fffff47284d950c8 fffff472907b7c08 ffff89f458e412b8 [445771.633713] raw: 0000000000001d00 ffff89f6c51d1a90 00000002ffffffff ffff89f400351b00 [445771.635029] page dumped because: eb page dump [445771.635825] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=10 ino=258, invalid nlink: has 2 expect no more than 1 for dir [445771.638088] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14878 owner 5 [445771.638091] BTRFS info (device dm-0): refs 4 lock_owner 0 current 3581087 [445771.638094] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160 [445771.638097] \t\tinode generation 3 transid 9 size 16 nbytes 16384 [445771.638098] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0 [445771.638100] \t\trdev 0 sequence 2 flags 0x0 [445771.638102] \t\tatime 1775744884.0 [445771.660056] \t\tctime 1775744885.645502983 [445771.660058] \t\tmtime 1775744885.645502983 [445771.660060] \t\totime 1775744884.0 [445771.660062] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12 [445771.660064] \t\tindex 0 name_len 2 [445771.660066] \titem 2 key (256 DIR_ITEM 1843588421) itemoff 16077 itemsize 34 [445771.660068] \t\tlocation key (259 1 0) type 2 [445771.660070] \t\ttransid 9 data_len 0 name_len 4 [445771.660075] \titem 3 key (256 DIR_ITEM 2363071922) itemoff 16043 itemsize 34 [445771.660076] \t\tlocation key (257 1 0) type 2 [445771.660077] \t\ttransid 9 data_len 0 name_len 4 [445771.660078] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34 [445771.660079] \t\tlocation key (257 1 0) type 2 [445771.660080] \t\ttransid 9 data_len 0 name_len 4 [445771.660081] \titem 5 key (256 DIR_INDEX 3) itemoff 15975 itemsize 34 [445771.660082] \t\tlocation key (259 1 0) type 2 [445771.660083] \t\ttransid 9 data_len 0 name_len 4 [445771.660084] \titem 6 key (257 INODE_ITEM 0) itemoff 15815 itemsize 160 [445771.660086] \t\tinode generation 9 transid 9 size 8 nbytes 0 [445771.660087] \t\tblock group 0 mode 40777 links 1 uid 0 gid 0 [445771.660088] \t\trdev 0 sequence 2 flags 0x0 [445771.660089] \t\tatime 1775744885.641174097 [445771.660090] \t\tctime 1775744885.645502983 [445771.660091] \t\tmtime 1775744885.645502983 [445771.660105] \t\totime 1775744885.641174097 [445771.660106] \titem 7 key (257 INODE_REF 256) itemoff 15801 itemsize 14 [445771.660107] \t\tindex 2 name_len 4 [445771.660108] \titem 8 key (257 DIR_ITEM 2676584006) itemoff 15767 itemsize 34 [445771.660109] \t\tlocation key (2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46195", "url": "https://ubuntu.com/security/CVE-2026-46195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. build_sec_desc() and id_mode_to_cifs_acl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths. Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.", "cve_priority": "high", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46292", "url": "https://ubuntu.com/security/CVE-2026-46292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: core: Fix detach procedure for virtual devices in genpd If a device is attached to a PM domain through genpd_dev_pm_attach_by_id(), genpd calls pm_runtime_enable() for the corresponding virtual device that it registers. While this avoids boilerplate code in drivers, there is no corresponding call to pm_runtime_disable() in genpd_dev_pm_detach(). This means these virtual devices are typically detached from its genpd, while runtime PM remains enabled for them, which is not how things are designed to work. In worst cases it may lead to critical errors, like a NULL pointer dereference bug in genpd_runtime_suspend(), which was recently reported. For another case, we may end up keeping an unnecessary vote for a performance state for the device. To fix these problems, let's add this missing call to pm_runtime_disable() in genpd_dev_pm_detach().", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46159", "url": "https://ubuntu.com/security/CVE-2026-46159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to info-leak btrfs_ioctl_space_info() has a TOCTOU race between two passes over the block group RAID type lists. The first pass counts entries to determine the allocation size, then the second pass fills the buffer. The groups_sem rwlock is released between passes, allowing concurrent block group removal to reduce the entry count. When the second pass fills fewer entries than the first pass counted, copy_to_user() copies the full alloc_size bytes including trailing uninitialized kmalloc bytes to userspace. Fix by copying only total_spaces entries (the actually-filled count from the second pass) instead of alloc_size bytes, and switch to kzalloc so any future copy size mismatch cannot leak heap data.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46191", "url": "https://ubuntu.com/security/CVE-2026-46191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Avoid OOB font access if console rotation fails Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example. Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer. v2: - fix typos in commit message", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46116", "url": "https://ubuntu.com/security/CVE-2026-46116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete KASAN reproduces a slab-use-after-free in __xfrm_state_delete()'s hlist_del_rcu calls under syzkaller load on linux-6.12.y stable (reproduced on 6.12.47, also reachable via the same code path on torvalds/master and on the ipsec tree). Nine unique signatures cluster in the xfrm_state lifecycle, the load-bearing one being: BUG: KASAN: slab-use-after-free in __hlist_del include/linux/list.h:990 [inline] BUG: KASAN: slab-use-after-free in hlist_del_rcu include/linux/rculist.h:516 [inline] BUG: KASAN: slab-use-after-free in __xfrm_state_delete net/xfrm/xfrm_state.c Write of size 8 at addr ffff8881198bcb70 by task kworker/u8:9/435 Workqueue: netns cleanup_net Call Trace: __hlist_del / hlist_del_rcu __xfrm_state_delete xfrm_state_delete xfrm_state_flush xfrm_state_fini ops_exit_list cleanup_net The other observed signatures hit the same slab object from __xfrm_state_lookup, xfrm_alloc_spi, __xfrm_state_insert and an OOB write variant of __xfrm_state_delete, all on the byseq/byspi hash chains. __xfrm_state_delete() guards its byseq and byspi unhashes with value-based predicates: \tif (x->km.seq) \t\thlist_del_rcu(&x->byseq); \tif (x->id.spi) \t\thlist_del_rcu(&x->byspi); while everywhere else in the file (e.g. state_cache, state_cache_input) the safer hlist_unhashed() check is used. xfrm_alloc_spi() sets x->id.spi = newspi inside xfrm_state_lock and then immediately inserts into byspi, but a path that observes x->id.spi != 0 outside of xfrm_state_lock can still skip-or-hit the byspi unhash inconsistently with whether x is actually on the list. The same holds for x->km.seq versus byseq, and the bydst/bysrc unhashes have no predicate at all, so a second __xfrm_state_delete() on the same object writes through LIST_POISON pprev. The defensive change here: - Use hlist_del_init_rcu() instead of hlist_del_rcu() on bydst, bysrc, byseq and byspi so a second deletion is a no-op rather than a write through LIST_POISON pprev. The byseq/byspi nodes are already initialised in xfrm_state_alloc(). - Test hlist_unhashed() rather than the value predicate for byseq/byspi, so the unhash decision tracks list state rather than mutable scalar fields. Empirical verification: applied this patch on top of v6.12.47, rebuilt, and re-ran the same syzkaller harness for 1h16m on a previously-crashy configuration that produced ~100 hits each of slab-use-after-free Read in xfrm_alloc_spi / Read in __xfrm_state_lookup / Write in __xfrm_state_delete. After the patch, 7.1M execs across 32 VMs at ~1550 exec/sec produced zero xfrm_state UAF/OOB hits. /proc/slabinfo confirms the xfrm_state slab is actively allocated and freed during the run (~143 KiB resident), so the fuzzer is still exercising those code paths -- they just no longer crash. Reproduction: - Linux 6.12.47 x86_64 + KASAN_GENERIC + KASAN_INLINE + KCOV - syzkaller @ 746545b8b1e4c3a128db8652b340d3df90ce61db - 32 QEMU/KVM VMs x 2 vCPU on AWS c5.metal bare metal - 9 unique signatures collected in ~9h, all within xfrm_state lifecycle", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46193", "url": "https://ubuntu.com/security/CVE-2026-46193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: ah: account for ESN high bits in async callbacks AH allocates its temporary auth/ICV layout differently when ESN is enabled: the async ahash setup appends a 4-byte seqhi slot before the ICV or auth_data area, but the async completion callbacks still reconstruct the temporary layout as if seqhi were absent. With an async AH implementation selected, that makes AH copy or compare the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH with ESN and forced async hmac(sha1), ping fails with 100% packet loss, and the callback logs show the pre-fix drift: ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36 Reconstruct the callback-side layout the same way the setup path built it by skipping the ESN seqhi slot before locating the saved auth_data or ICV. Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV computation, so the async callbacks must account for the seqhi slot. Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the change has not been tested against a real async hardware AH engine.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46180", "url": "https://ubuntu.com/security/CVE-2026-46180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix potential use-after-free issue when stopping watchdog task Watchdog task might end between send_sig() and kthread_stop() calls, what results in the use-after-free issue. Fix this by increasing watchdog task reference count before calling send_sig() and dropping it by switching to kthread_stop_put().", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-31709", "url": "https://ubuntu.com/security/CVE-2026-31709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-46196", "url": "https://ubuntu.com/security/CVE-2026-46196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -> 1 transition, tracepoint_add_func() invokes the subsystem's ext->regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-46291", "url": "https://ubuntu.com/security/CVE-2026-46291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled.", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46090", "url": "https://ubuntu.com/security/CVE-2026-46090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream. Commit 826af7fa62e3 (\"ALSA: aloop: Fix racy access at PCM trigger\") moved the peer lookup under cable->lock, but the actual snd_pcm_stop() still runs after dropping that lock. A concurrent close can clear the capture entry from cable->streams[] and detach or free its runtime while the playback trigger path still holds a stale peer substream pointer. Keep a per-cable count of in-flight peer stops before dropping cable->lock, and make free_cable() wait for those stops before detaching the runtime. This preserves the existing behavior while making the peer runtime lifetime explicit.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46052", "url": "https://ubuntu.com/security/CVE-2026-46052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: only d_add() negative dentries when they are unhashed Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash. In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume \"negative\" also means \"unhashed\": - ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL) - ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL) Both paths can therefore re-add an already-hashed negative dentry. Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true. Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is. This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45999", "url": "https://ubuntu.com/security/CVE-2026-45999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap() Some crafted images can have illegal (!partial_decoding && m_llen < m_plen) extents, and the LZ4 inplace decompression path can be wrongly hit, but it cannot handle (outpages < inpages) properly: \"outpages - inpages\" wraps to a large value and the subsequent rq->out[] access reads past the decompressed_pages array. However, such crafted cases can correctly result in a corruption report in the normal LZ4 non-inplace path. Let's add an additional check to fix this for backporting. Reproducible image (base64-encoded gzipped blob): H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w ywAAAAAAAADwu14ATsEYtgBQAAA= $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt $ dd if=/mnt/data of=/dev/null bs=4096 count=1", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46103", "url": "https://ubuntu.com/security/CVE-2026-46103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: ucan: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the control message buffer lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46056", "url": "https://ubuntu.com/security/CVE-2026-46056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: fix potential UAF in SSP passkey handlers hci_conn lookup and field access must be covered by hdev lock in hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise the connection can be freed concurrently. Extend the hci_dev_lock critical section to cover all conn usage in both handlers. Keep the existing keypress notification behavior unchanged by routing the early exits through a common unlock path.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46299", "url": "https://ubuntu.com/security/CVE-2026-46299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix held lock freed on hfsplus_fill_super() hfsplus_fill_super() calls hfs_find_init() to initialize a search structure, which acquires tree->tree_lock. If the subsequent call to hfsplus_cat_build_key() fails, the function jumps to the out_put_root error label without releasing the lock. The later cleanup path then frees the tree data structure with the lock still held, triggering a held lock freed warning. Fix this by adding the missing hfs_find_exit(&fd) call before jumping to the out_put_root error label. This ensures that tree->tree_lock is properly released on the error path. The bug was originally detected on v6.13-rc1 using an experimental static analysis tool we are developing, and we have verified that the issue persists in the latest mainline kernel. The tool is specifically designed to detect memory management issues. It is currently under active development and not yet publicly available. We confirmed the bug by runtime testing under QEMU with x86_64 defconfig, lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we used GDB to dynamically shrink the max_unistr_len parameter to 1 before hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and exercises the faulty error path. The following warning was observed during mount: \t========================= \tWARNING: held lock freed! \t7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted \t------------------------- \tmount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there! \tffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \t2 locks held by mount/174: \t#0: ffff888103f960e0 (&type->s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40 \t#1: ffff888103f920b0 (&tree->tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0 \tstack backtrace: \tCPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy) \tHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 \tCall Trace: \t \tdump_stack_lvl+0x82/0xd0 \tdebug_check_no_locks_freed+0x13a/0x180 \tkfree+0x16b/0x510 \t? hfsplus_fill_super+0xcb4/0x18a0 \thfsplus_fill_super+0xcb4/0x18a0 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x65f/0xc30 \t? srso_return_thunk+0x5/0x5f \t? pointer+0x4ce/0xbf0 \t? trace_contention_end+0x11c/0x150 \t? __pfx_pointer+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? bdev_open+0x79b/0xc30 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? vsnprintf+0x6da/0x1270 \t? srso_return_thunk+0x5/0x5f \t? __mutex_unlock_slowpath+0x157/0x740 \t? __pfx_vsnprintf+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? mark_held_locks+0x49/0x80 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? irqentry_exit+0x17b/0x5e0 \t? trace_irq_disable.constprop.0+0x116/0x150 \t? __pfx_hfsplus_fill_super+0x10/0x10 \t? __pfx_hfsplus_fill_super+0x10/0x10 \tget_tree_bdev_flags+0x302/0x580 \t? __pfx_get_tree_bdev_flags+0x10/0x10 \t? vfs_parse_fs_qstr+0x129/0x1a0 \t? __pfx_vfs_parse_fs_qstr+0x3/0x10 \tvfs_get_tree+0x89/0x320 \tfc_mount+0x10/0x1d0 \tpath_mount+0x5c5/0x21c0 \t? __pfx_path_mount+0x10/0x10 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \t? srso_return_thunk+0x5/0x5f \t? kmem_cache_free+0x307/0x540 \t? user_path_at+0x51/0x60 \t? __x64_sys_mount+0x212/0x280 \t? srso_return_thunk+0x5/0x5f \t__x64_sys_mount+0x212/0x280 \t? __pfx___x64_sys_mount+0x10/0x10 \t? srso_return_thunk+0x5/0x5f \t? trace_irq_enable.constprop.0+0x116/0x150 \t? srso_return_thunk+0x5/0x5f \tdo_syscall_64+0x111/0x680 \tentry_SYSCALL_64_after_hwframe+0x77/0x7f \tRIP: 0033:0x7ffacad55eae \tCode: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8 \tRSP: 002b ---truncated---", "cve_priority": "low", "cve_public_date": "2026-06-08 17:16:00 UTC" }, { "cve": "CVE-2026-46169", "url": "https://ubuntu.com/security/CVE-2026-46169", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value by validating catalog record size Syzbot reported a KMSAN uninit-value issue in hfsplus_strcasecmp(). The root cause is that hfs_brec_read() doesn't validate that the on-disk record size matches the expected size for the record type being read. When mounting a corrupted filesystem, hfs_brec_read() may read less data than expected. For example, when reading a catalog thread record, the debug output showed: HFSPLUS_BREC_READ: rec_len=520, fd->entrylength=26 HFSPLUS_BREC_READ: WARNING - entrylength (26) < rec_len (520) - PARTIAL READ! hfs_brec_read() only validates that entrylength is not greater than the buffer size, but doesn't check if it's less than expected. It successfully reads 26 bytes into a 520-byte structure and returns success, leaving 494 bytes uninitialized. This uninitialized data in tmp.thread.nodeName then gets copied by hfsplus_cat_build_key_uni() and used by hfsplus_strcasecmp(), triggering the KMSAN warning when the uninitialized bytes are used as array indices in case_fold(). Fix by introducing hfsplus_brec_read_cat() wrapper that: 1. Calls hfs_brec_read() to read the data 2. Validates the record size based on the type field: - Fixed size for folder and file records - Variable size for thread records (depends on string length) 3. Returns -EIO if size doesn't match expected For thread records, check against HFSPLUS_MIN_THREAD_SZ before reading nodeName.length to avoid reading uninitialized data at call sites that don't zero-initialize the entry structure. Also initialize the tmp variable in hfsplus_find_cat() as defensive programming to ensure no uninitialized data even if validation is bypassed.", "cve_priority": "medium", "cve_public_date": "2026-05-28 10:16:00 UTC" }, { "cve": "CVE-2026-45991", "url": "https://ubuntu.com/security/CVE-2026-45991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: udf: fix partition descriptor append bookkeeping Mounting a crafted UDF image with repeated partition descriptors can trigger a heap out-of-bounds write in part_descs_loc[]. handle_partition_descriptor() deduplicates entries by partition number, but appended slots never record partnum. As a result duplicate Partition Descriptors are appended repeatedly and num_part_descs keeps growing. Once the table is full, the growth path still sizes the allocation from partnum even though inserts are indexed by num_part_descs. If partnum is already aligned to PART_DESC_ALLOC_STEP, ALIGN(partnum, step) can keep the old capacity and the next append writes past the end of the table. Store partnum in the appended slot and size growth from the next append count so deduplication and capacity tracking follow the same model.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46065", "url": "https://ubuntu.com/security/CVE-2026-46065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal. Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46086", "url": "https://ubuntu.com/security/CVE-2026-46086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: bridge: use a stable FDB dst snapshot in RCU readers Local FDB entries can be rewritten in place by `fdb_delete_local()`, which updates `f->dst` to another port or to `NULL` while keeping the entry alive. Several bridge RCU readers inspect `f->dst`, including `br_fdb_fillbuf()` through the `brforward_read()` sysfs path. These readers currently load `f->dst` multiple times and can therefore observe inconsistent values across the check and later dereference. In `br_fdb_fillbuf()`, this means a concurrent local-FDB update can change `f->dst` after the NULL check and before the `port_no` dereference, leading to a NULL-ptr-deref. Fix this by taking a single `READ_ONCE()` snapshot of `f->dst` in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place `f->dst` updates in `fdb_delete_local()` with `WRITE_ONCE()` so the readers and writer use matching access patterns.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46003", "url": "https://ubuntu.com/security/CVE-2026-46003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the total number of nodes Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion. Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46038", "url": "https://ubuntu.com/security/CVE-2026-46038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Free the node during ctrl_cmd_bye() A node sends the BYE packet when it is about to go down. So the nameserver should advertise the removal of the node to all remote and local observers and free the node finally. But currently, the nameserver doesn't free the node memory even after processing the BYE packet. This causes the node memory to leak. Hence, remove the node from Xarray list and free the node memory during both success and failure case of ctrl_cmd_bye().", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46026", "url": "https://ubuntu.com/security/CVE-2026-46026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Limit the maximum number of lookups Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEW_LOOKUP messages over the same socket. Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46091", "url": "https://ubuntu.com/security/CVE-2026-46091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rc: igorplugusb: heed coherency rules In a control request, the USB request structure can be subject to DMA on some HCs. Hence it must obey the rules for DMA coherency. Allocate it separately.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46078", "url": "https://ubuntu.com/security/CVE-2026-46078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: fix the out-of-bounds nameoff handling for trailing dirents Currently we already have boundary-checks for nameoffs, but the trailing dirents are special since the namelens are calculated with strnlen() with unchecked nameoffs. If a crafted EROFS has a trailing dirent with nameoff >= maxsize, maxsize - nameoff can underflow, causing strnlen() to read past the directory block. nameoff0 should also be verified to be a multiple of `sizeof(struct erofs_dirent)` as well [1]. [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46069", "url": "https://ubuntu.com/security/CVE-2026-46069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup() The mwifiex_adapter_cleanup() function uses timer_delete() (non-synchronous) for the wakeup_timer before the adapter structure is freed. This is incorrect because timer_delete() does not wait for any running timer callback to complete. If the wakeup_timer callback (wakeup_timer_fn) is executing when mwifiex_adapter_cleanup() is called, the callback will continue to access adapter fields (adapter->hw_status, adapter->if_ops.card_reset, etc.) which may be freed by mwifiex_free_adapter() called later in the mwifiex_remove_card() path. Use timer_delete_sync() instead to ensure any running timer callback has completed before returning.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46021", "url": "https://ubuntu.com/security/CVE-2026-46021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix thermal zone governor cleanup issues If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-46092", "url": "https://ubuntu.com/security/CVE-2026-46092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: check for PCI upstream bridge existence pci_upstream_bridge() returns NULL if the device is on a root bus. If 8821CE is installed in the system with such a PCI topology, the probing routine will crash. This has probably been unnoticed as 8821CE is mostly supplied in laptops where there is a PCI-to-PCI bridge located upstream from the device. However the card might be installed on a system with different configuration. Check if the bridge does exist for the specific workaround to be applied. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-31700", "url": "https://ubuntu.com/security/CVE-2026-31700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd() In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points directly into the mmap'd TX ring buffer shared with userspace. The kernel validates the header via __packet_snd_vnet_parse() but then re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent userspace thread can modify the vnet_hdr fields between validation and use, bypassing all safety checks. The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr to a stack-local variable. All other vnet_hdr consumers in the kernel (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX path is the only caller of virtio_net_hdr_to_skb() that reads directly from user-controlled shared memory. Fix this by copying vnet_hdr from the mmap'd ring buffer to a stack-local variable before validation and use, consistent with the approach used in packet_snd() and all other callers.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31712", "url": "https://ubuntu.com/security/CVE-2026-31712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: require minimum ACE size in smb_check_perm_dacl() Both ACE-walk loops in smb_check_perm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared `ace->size` is smaller than the struct it claims to describe: if (offsetof(struct smb_ace, access_req) > aces_size) break; ace_size = le16_to_cpu(ace->size); if (ace_size > aces_size) break; The first check only requires the 4-byte ACE header to be in bounds; it does not require access_req (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with aces_size == 4, pass both checks, and then granted |= le32_to_cpu(ace->access_req); /* upper loop */ compare_sids(&sid, &ace->sid); /* lower loop */ reads access_req at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFS_SID_BASE_SIZE + SID_MAX_SUB_AUTHORITIES * 4 bytes). Tighten both loops to require ace_size >= offsetof(struct smb_ace, sid) + CIFS_SID_BASE_SIZE which is the smallest valid on-wire ACE layout (4-byte header + 4-byte access_req + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.num_subauth exceeds SID_MAX_SUB_AUTHORITIES before letting compare_sids() dereference sub_auth[] entries. parse_sec_desc() already enforces an equivalent check (lines 441-448); smb_check_perm_dacl() simply grew weaker validation over time. Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smb_check_perm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31708", "url": "https://ubuntu.com/security/CVE-2026-31708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. The QUERY_INFO branch clamps qi.input_buffer_length to the server-reported OutputBufferLength and then copies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, but it never verifies that the flexible-array payload actually fits within rsp_iov[1].iov_len. A malicious server can return OutputBufferLength larger than the actual QUERY_INFO response, causing copy_to_user() to walk past the response buffer and expose adjacent kernel heap to userspace. Guard the QUERY_INFO copy with a bounds check on the actual Buffer payload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length) rather than an open-coded addition so the guard cannot overflow on 32-bit builds.", "cve_priority": "high", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43350", "url": "https://ubuntu.com/security/CVE-2026-43350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: require a full NFS mode SID before reading mode bits parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS mode SID and reads sid.sub_auth[2] to recover the mode bits. That assumes the ACE carries three subauthorities, but compare_sids() only compares min(a, b) subauthorities. A malicious server can return an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still matches sid_unix_NFS_mode and then drives the sub_auth[2] read four bytes past the end of the ACE. Require num_subauth >= 3 before treating the ACE as an NFS mode SID. This keeps the fix local to the special-SID mode path without changing compare_sids() semantics for the rest of cifsacl.", "cve_priority": "medium", "cve_public_date": "2026-05-08 14:16:00 UTC" }, { "cve": "CVE-2026-31711", "url": "https://ubuntu.com/security/CVE-2026-31711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: server: fix active_num_conn leak on transport allocation failure Commit 77ffbcac4e56 (\"smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()\") addressed the kthread_run() failure path. The earlier alloc_transport() == NULL path in the same function has the same leak, is reachable pre-authentication via any TCP connect to port 445, and was empirically reproduced on UML (ARCH=um, v7.0-rc7): a small number of forced allocation failures were sufficient to put ksmbd into a state where every subsequent connection attempt was rejected for the remainder of the boot. ksmbd_kthread_fn() increments active_num_conn before calling ksmbd_tcp_new_connection() and discards the return value, so when alloc_transport() returns NULL the socket is released and -ENOMEM returned without decrementing the counter. Each such failure permanently consumes one slot from the max_connections pool; once cumulative failures reach the cap, atomic_inc_return() hits the threshold on every subsequent accept and every new connection is rejected. The counter is only reset by module reload. An unauthenticated remote attacker can drive the server toward the memory pressure that makes alloc_transport() fail by holding open connections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN (0x00FFFFFF); natural transient allocation failures on a loaded host produce the same drift more slowly. Mirror the existing rollback pattern in ksmbd_kthread_fn(): on the alloc_transport() failure path, decrement active_num_conn gated on server_conf.max_connections. Repro details: with the patch reverted, forced alloc_transport() NULL returns leaked counter slots and subsequent connection attempts -- including legitimate connects issued after the forced-fail window had closed -- were all rejected with \"Limit the maximum number of connections\". With this patch applied, the same connect sequence produces no rejections and the counter cycles cleanly between zero and one on every accept.", "cve_priority": "medium", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-31715", "url": "https://ubuntu.com/security/CVE-2026-31715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io() The xfstests case \"generic/107\" and syzbot have both reported a NULL pointer dereference. The concurrent scenario that triggers the panic is as follows: F2FS_WB_CP_DATA write callback umount - f2fs_write_checkpoint - f2fs_wait_on_all_pages(sbi, F2FS_WB_CP_DATA) - blk_mq_end_request - bio_endio - f2fs_write_end_io : dec_page_count(sbi, F2FS_WB_CP_DATA) : wake_up(&sbi->cp_wait) - kill_f2fs_super - kill_block_super - f2fs_put_super : iput(sbi->node_inode) : sbi->node_inode = NULL : f2fs_in_warm_node_list - is_node_folio // sbi->node_inode is NULL and panic The root cause is that f2fs_put_super() calls iput(sbi->node_inode) and sets sbi->node_inode to NULL after sbi->nr_pages[F2FS_WB_CP_DATA] is decremented to zero. As a result, f2fs_in_warm_node_list() may dereference a NULL node_inode when checking whether a folio belongs to the node inode, leading to a panic. This patch fixes the issue by calling f2fs_in_warm_node_list() before decrementing sbi->nr_pages[F2FS_WB_CP_DATA], thus preventing the use-after-free condition.", "cve_priority": "low", "cve_public_date": "2026-05-01 14:16:00 UTC" }, { "cve": "CVE-2026-43492", "url": "https://ubuntu.com/security/CVE-2026-43492", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl() Yiming reports an integer underflow in mpi_read_raw_from_sgl() when subtracting \"lzeros\" from the unsigned \"nbytes\". For this to happen, the scatterlist \"sgl\" needs to occupy more bytes than the \"nbytes\" parameter and the first \"nbytes + 1\" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than \"nbytes\", subtract the number of zeroes from \"nbytes\" and cause the underflow. When commit 2d4d1eea540b (\"lib/mpi: Add mpi sgl helpers\") originally introduced the bug, it couldn't be triggered because all callers of mpi_read_raw_from_sgl() passed a scatterlist whose length was equal to \"nbytes\". However since commit 63ba4d67594a (\"KEYS: asymmetric: Use new crypto interface without scatterlists\"), the underflow can now actually be triggered. When invoking a KEYCTL_PKEY_ENCRYPT system call with a larger \"out_len\" than \"in_len\" and filling the \"in\" buffer with zeroes, crypto_akcipher_sync_prep() will create an all-zero scatterlist used for both the \"src\" and \"dst\" member of struct akcipher_request and thereby fulfil the conditions to trigger the bug: sys_keyctl() keyctl_pkey_e_d_s() asymmetric_key_eds_op() software_key_eds_op() crypto_akcipher_sync_encrypt() crypto_akcipher_sync_prep() crypto_akcipher_encrypt() rsa_enc() mpi_read_raw_from_sgl() To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect. Fix it.", "cve_priority": "medium", "cve_public_date": "2026-05-19 12:16:00 UTC" }, { "cve": "CVE-2026-43383", "url": "https://ubuntu.com/security/CVE-2026-43383", "cve_description": "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.", "cve_priority": "medium", "cve_public_date": "2026-05-08 15:16:00 UTC" }, { "cve": "CVE-2026-52933", "url": "https://ubuntu.com/security/CVE-2026-52933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/poll: fix signed comparison in io_poll_get_ownership() io_poll_get_ownership() uses a signed comparison to check whether poll_refs has reached the threshold for the slowpath: if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS)) atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG (BIT(31)) is set in poll_refs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken. Fix this by casting the atomic_read() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53135", "url": "https://ubuntu.com/security/CVE-2026-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs [Why & How] dp_sdp_message_debugfs_write() dereferences connector->base.state->crtc without checking for NULL. A connector can be connected but not bound to any CRTC (e.g. after hot-plug before the next atomic commit), causing a kernel crash when writing to the sdp_message debugfs node. The function also ignores the user-provided size argument and always passes 36 bytes to copy_from_user(), reading past the user buffer when size < 36. Fix both issues by: - Returning -ENODEV when connector->base.state or state->crtc is NULL - Clamping write_size to min(size, sizeof(data)) (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53136", "url": "https://ubuntu.com/security/CVE-2026-53136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp VBIOS HDMI retimer register count to array size [Why & How] The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9] and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe. Clamp each register count to the destination array size using min_t() before the copy loops, in both get_integrated_info_v11() and get_integrated_info_v2_1(). (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53137", "url": "https://ubuntu.com/security/CVE-2026-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size [Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rx_id_list[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read. Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the rx_id_list buffer, matching the approach already used in the DP branch. (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53146", "url": "https://ubuntu.com/security/CVE-2026-53146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Limit XDomain response copy to actual frame size tb_xdomain_copy() copies req->response_size bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions. Use the minimum of frame size and expected response size for the copy length.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53148", "url": "https://ubuntu.com/security/CVE-2026-53148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Clamp XDomain response data copy to allocation size tb_xdp_properties_request() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared data_length, causing memcpy to write past the kcalloc allocation. Clamp the per-packet copy length so that the cumulative offset never exceeds data_len.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53149", "url": "https://ubuntu.com/security/CVE-2026-53149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Bound root directory content to block size __tb_property_parse_dir() does not check that content_offset + content_len fits within block_len for the root directory case. When rootdir->length equals or exceeds block_len - 2, the entry loop reads past the allocated property block. Add a bounds check after computing content_offset and content_len to reject directories whose content extends past the block.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53150", "url": "https://ubuntu.com/security/CVE-2026-53150", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Reject zero-length property entries in validator tb_property_entry_valid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic: property->value.text[property->length * 4 - 1] = '\\0'; When property->length is 0 this writes to offset -1 relative to the allocation. Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52929", "url": "https://ubuntu.com/security/CVE-2026-52929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: stream: fully roll back denied add-stream state When ADD_OUT_STREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path. Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctp_stream_outq_migrate(), and then reschedule the remaining streams. This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52917", "url": "https://ubuntu.com/security/CVE-2026-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: diag: reject stale associations in dump_one path The SCTP exact sock_diag lookup can hold a transport reference, block on lock_sock(sk), and then resume after sctp_association_free() has marked the association dead and freed its bind address list. When that happens, inet_assoc_attr_size() and inet_diag_msg_sctpasoc_fill() can still dereference association state that is no longer valid for reporting. In particular, inet_diag_msg_sctpasoc_fill() may read an empty bind-address list as a real sctp_sockaddr_entry and trigger an out-of-bounds read from unrelated association memory. Reject the association after taking the socket lock if it has been reaped or detached from the endpoint, and report the lookup as stale. This keeps the exact dump-one path from formatting torn association state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53159", "url": "https://ubuntu.com/security/CVE-2026-53159", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix DMA address corruption due to find_vma misuse fastrpc_get_args() uses find_vma() to look up the VMA for a user-provided pointer and compute a DMA address offset. When the address falls in a gap before the returned VMA, (ptr & PAGE_MASK) - vma->vm_start underflows, corrupting the DMA address sent to the DSP. Replace find_vma() with vma_lookup(), which returns NULL when the address is not contained within any VMA.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53161", "url": "https://ubuntu.com/security/CVE-2026-53161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context There is a race between fastrpc_device_release() and the workqueue that processes DSP responses. When the user closes the file descriptor, fastrpc_device_release() frees the fastrpc_user structure. Concurrently, an in-flight DSP invocation can complete and fastrpc_rpmsg_callback() schedules context cleanup via schedule_work(&ctx->put_work). If the workqueue runs fastrpc_context_free() in parallel with or after fastrpc_device_release() has freed the user structure, it dereferences the freed fastrpc_user. Depending on the state of the context at the time of the race, any one of the following accesses can be hit: 1. fastrpc_buf_free() calls fastrpc_ipa_to_dma_addr(buf->fl->cctx, ...) to strip the SID bits from the stored IOVA before passing the physical address to dma_free_coherent(). 2. fastrpc_free_map() reads map->fl->cctx->vmperms[0].vmid to reconstruct the source permission bitmask needed for the qcom_scm_assign_mem() call that returns memory from the DSP VM back to HLOS. 3. fastrpc_free_map() acquires map->fl->lock to safely remove the map node from the fl->maps list. The resulting use-after-free manifests as: pc : fastrpc_buf_free+0x38/0x80 [fastrpc] lr : fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_free+0xa8/0x1b0 [fastrpc] fastrpc_context_put_wq+0x78/0xa0 [fastrpc] process_one_work+0x180/0x450 worker_thread+0x26c/0x388 Add kref-based reference counting to fastrpc_user. Have each invoke context take a reference on the user at allocation time and release it when the context is freed. Release the initial reference in fastrpc_device_release() at file close. Move the teardown of the user structure — freeing pending contexts, maps, mmaps, and the channel context reference — into the kref release callback fastrpc_user_free(), so that it runs only when the last reference is dropped, regardless of whether that happens at device close or after the final in-flight context completes.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52930", "url": "https://ubuntu.com/security/CVE-2026-52930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53168", "url": "https://ubuntu.com/security/CVE-2026-53168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: reject fuse_notify() pagecache ops on directories The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the FUSE daemon to actively write/read pagecache contents. For directories with FOPEN_CACHE_DIR, the pagecache is used as kernel-internal cache storage, and userspace is not supposed to have direct access to this cache - in particular, fuse_parse_cache() will hit WARN_ON() if the cache contains bogus data. Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than regular files with -EINVAL.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53177", "url": "https://ubuntu.com/security/CVE-2026-53177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix NULL pointer dereference PCIe errors detected by a Root Port or Downstream Port cause error recovery services to run on all subordinate devices regardless of administrative state. The .error_detected() callback, bnxt_io_error_detected(), disables and synchronizes IRQs via bnxt_disable_int_sync(), which calls bnxt_cp_num_to_irq_num() to map completion rings to IRQs using bp->bnapi. Since bp->bnapi is allocated on NIC open and freed on NIC close, PCIe error recovery on a closed NIC can dereference a NULL pointer. Check if bp->bnapi is NULL before disabling and synchronizing IRQs.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53181", "url": "https://ubuntu.com/security/CVE-2026-53181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/vmci: fix sk_ack_backlog leak on failed handshake When vmci_transport_recv_connecting_server() returns an error, vmci_transport_recv_listen() calls vsock_remove_pending() but never calls sk_acceptq_removed(). This leaves sk_ack_backlog incremented permanently. Repeated handshake failures (malformed packets, queue pair alloc failure, event subscribe failure) cause sk_ack_backlog to climb toward sk_max_ack_backlog. Once it reaches the limit the listener permanently refuses all new connections with -ECONNREFUSED, a silent denial of service requiring a process restart to recover. The two existing sk_acceptq_removed() calls in af_vsock.c do not cover this path: line 764 checks vsock_is_pending() which returns false after vsock_remove_pending(), and line 1889 is only reached on successful accept(). Fix by balancing sk_acceptq_added() with sk_acceptq_removed() on the error path.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53194", "url": "https://ubuntu.com/security/CVE-2026-53194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: kl5kusb105: fix bulk-out buffer overflow klsi_105_prepare_write_buffer() is called by the generic write path with the bulk-out buffer and its size (bulk_out_size, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSI_HDR_LEN, but passes the full buffer size as the number of bytes to copy: count = kfifo_out_locked(&port->write_fifo, buf + KLSI_HDR_LEN, size, &port->lock); When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSI_HDR_LEN bytes past its end. Copy at most size - KLSI_HDR_LEN bytes instead, leaving room for the header as safe_serial already does. Writing bulk_out_size or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget: BUG: KASAN: slab-out-of-bounds in kfifo_copy_out+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifo_copy_out klsi_105_prepare_write_buffer [kl5kusb105] usb_serial_generic_write_start [usbserial] Allocated by task 139: usb_serial_probe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region The out-of-bounds write no longer occurs with this change applied.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53195", "url": "https://ubuntu.com/security/CVE-2026-53195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr() build_i2c_fw_hdr() allocates a fixed-size buffer of (16*1024 - 512) + sizeof(struct ti_i2c_firmware_rec) bytes, then copies le16_to_cpu(img_header->Length) bytes into it without validating that Length fits within the available space after the firmware record header. img_header->Length is a __le16 from the firmware file and can be up to 65535. check_fw_sanity() validates the total firmware size but not img_header->Length specifically. Fix by rejecting images where img_header->Length exceeds the available destination space.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53196", "url": "https://ubuntu.com/security/CVE-2026-53196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52935", "url": "https://ubuntu.com/security/CVE-2026-52935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: do not reuse an in-progress partial send espintcp keeps a single in-flight transmit in ctx->partial. Before building a new sk_msg, espintcp_sendmsg() first tries to flush that state through espintcp_push_msgs(). For blocking callers, espintcp_push_msgs() may return success even when the previous partial send is still pending. espintcp_sendmsg() would then reinitialize emsg->skmsg and reuse ctx->partial while the old transfer still owns that state. Do not rebuild the send message when ctx->partial is still in progress. If espintcp_push_msgs() returns with emsg->len still set, fail the new send instead of overwriting the live partial state. This is a memory-safety fix: reusing the live partial-send state can leave a stale offset attached to a new sk_msg and lead to an out-of- bounds read in the send path. tcp_sendmsg_locked() already handles waiting for send buffer memory, so the fix here is just to preserve espintcp's one-message-at-a-time transmit state.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53208", "url": "https://ubuntu.com/security/CVE-2026-53208", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR signaling packets up to the channel MTU and dispatches each command without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer within radio range can send a fixed-channel CID 0x0001 packet that is larger than MTUsig and contains many L2CAP_ECHO_REQ commands before pairing. In a real-radio stock-kernel run, one 681-byte signaling packet containing 168 zero-length ECHO_REQ commands made the target transmit 168 ECHO_RSP frames over about 220 ms. Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling packet containing packed ECHO_REQ commands. Define Linux's BR/EDR signaling MTU as the spec minimum of 48 bytes and reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched. The Bluetooth Core spec wording for MTUExceeded says the reject identifier shall match the first request command in the packet, and that packets containing only responses shall be silently discarded. Linux intentionally deviates from that prescription: silently discarding desynchronizes the peer because the remote stack never learns its responses were dropped, and locating the first request command requires walking command headers past MTUsig, i.e. processing bytes from a packet we have already decided is too large to process. We therefore always emit one reject and use the identifier from the first command header, a single fixed-offset byte read. The unrestricted BR/EDR signaling parser and ECHO_REQ response path both trace to the initial git import; no later introducing commit is available for a Fixes tag.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53213", "url": "https://ubuntu.com/security/CVE-2026-53213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: fix krealloc() memory leak Don't just overwrite the original pointer passed to krealloc() with its return value without checking latter: MEM = krealloc(MEM, SZ, GFP); If krealloc() returns NULL, that erases the pointer to the still allocated memory, hence leaks this memory. Instead, use a temporary variable, check it's not NULL and only then assign it to the original pointer: TMP = krealloc(MEM, SZ, GFP); if (!TMP) return; MEM = TMP; While on it, use krealloc_array().", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53217", "url": "https://ubuntu.com/security/CVE-2026-53217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: sync RX data at the hardware packet offset mvpp2 programs the RX queue packet offset, so hardware writes received data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the unused headroom and misses the same number of bytes at the packet tail. On non-coherent DMA systems this can leave the CPU reading stale cache contents for the end of the received frame. Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range offset so the sync covers the Marvell header and packet data actually written by hardware.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53218", "url": "https://ubuntu.com/security/CVE-2026-53218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52942", "url": "https://ubuntu.com/security/CVE-2026-52942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_log: validate MAC header was set before dumping it The fallback path of dump_mac_header() guards the MAC header access only with \"skb->mac_header != skb->network_header\", without checking skb_mac_header_was_set(). When the MAC header is unset, mac_header is 0xffff, so the test passes and skb_mac_header(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hard_header_len bytes out of bounds into the kernel log. This is reachable via the netdev logger: nf_log_unknown_packet() calls dump_mac_header() unconditionally, and an skb sent through AF_PACKET with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still unset (__dev_queue_xmit(), which would reset it, is bypassed). Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already uses, and replace the open-coded MAC header length test with skb_mac_header_len(). Only skbs with an unset MAC header are affected; valid ones are dumped as before. BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasan_report (mm/kasan/report.c:595) dump_mac_header (net/netfilter/nf_log_syslog.c:831) nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963) nf_log_packet (net/netfilter/nf_log.c:260) nft_log_eval (net/netfilter/nft_log.c:60) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307) nf_hook_slow (net/netfilter/core.c:619) nf_hook_direct_egress (net/packet/af_packet.c:257) packet_xmit (net/packet/af_packet.c:280) packet_sendmsg (net/packet/af_packet.c:3114) __sys_sendto (net/socket.c:2265)", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53219", "url": "https://ubuntu.com/security/CVE-2026-53219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52939", "url": "https://ubuntu.com/security/CVE-2026-52939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic completion rds_ib_xmit_atomic() always programs a masked atomic opcode (IB_WR_MASKED_ATOMIC_CMP_AND_SWP or IB_WR_MASKED_ATOMIC_FETCH_AND_ADD) for every RDS atomic cmsg. But the completion-side switch in rds_ib_send_unmap_op() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->s_op is left set. rds_ib_send_cqe_handler() then dereferences the NULL rm via rm->m_final_op, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed. RDS/IB: rds_ib_send_unmap_op: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rds_ib_send_cqe_handler+0x25c/0xb10 (net/rds/ib_send.c:282) Call Trace: rds_ib_send_cqe_handler (net/rds/ib_send.c:282) poll_scq (net/rds/ib_cm.c:274) rds_ib_tasklet_fn_send (net/rds/ib_cm.c:294) tasklet_action_common (kernel/softirq.c:943) handle_softirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) Kernel panic - not syncing: Fatal exception in interrupt Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rds_message.atomic union member, so the existing container_of()/rds_ib_send_unmap_atomic() body is correct for them.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-53223", "url": "https://ubuntu.com/security/CVE-2026-53223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53227", "url": "https://ubuntu.com/security/CVE-2026-53227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the \"Fixes\" tag, the allocation of the \"reply\" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming \"reply\" is allocated before locking: it is freed after unlocking. If \"reply\" allocation happens after locking the mutex and it fails, \"reply\" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52947", "url": "https://ubuntu.com/security/CVE-2026-52947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove In qrtr_port_remove(), the socket reference count is decremented via __sock_put() before the port is removed from the qrtr_ports XArray and before the RCU grace period elapses. This breaks the fundamental RCU update paradigm. It exposes a race window where a concurrent RCU reader (such as qrtr_reset_ports() or qrtr_port_lookup()) can obtain a pointer to the socket from the XArray, and attempt to call sock_hold() on a socket whose reference count has already dropped to zero. This exact race condition was hit during syzkaller fuzzing, leading to the following refcount saturation warning and a potential Use-After-Free: refcount_t: saturated; leaking memory. WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0 Modules linked in: qrtr(+) bochs drm_shmem_helper ... Call Trace: qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr] __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr] qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr] kernel_bind+0xe4/0x120 net/socket.c:3592 qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr] qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr] do_one_initcall+0xf5/0x5e0 init/main.c:1283 ... Fix this by deferring the reference count decrement until after the xa_erase() and the synchronize_rcu() complete. (Note: The v1 of this patch incorrectly replaced __sock_put() with sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove() still hold a reference to the socket, so freeing the socket memory here would lead to a subsequent UAF in the caller. Thus, the __sock_put() is kept, but only repositioned to close the RCU race.)", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53238", "url": "https://ubuntu.com/security/CVE-2026-53238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53239", "url": "https://ubuntu.com/security/CVE-2026-53239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-46322", "url": "https://ubuntu.com/security/CVE-2026-46322", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on build_skb failure in tun_xdp_one() When build_skb() fails in tun_xdp_one(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhost_net_build_xdp() allocated for the frame. As with the short-frame rejection path, tun_sendmsg() discards the per-buffer error and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page. Each build_skb() failure in a batch leaks one page-frag chunk. Free the page before taking the error path, matching the put_page() the other error exits of tun_xdp_one() already perform.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-46320", "url": "https://ubuntu.com/security/CVE-2026-46320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tap: free page on error paths in tap_get_user_xdp() tap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL, and returns -ENOMEM when build_skb() fails. Both paths jump to the err label without freeing the page that vhost_net_build_xdp() allocated for the frame. tap_sendmsg() discards the per-buffer return value and always returns 0, so vhost_tx_batch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk. Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tun_xdp_one().", "cve_priority": "high", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2025-22026", "url": "https://ubuntu.com/security/CVE-2025-22026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: don't ignore the return code of svc_proc_register() Currently, nfsd_proc_stat_init() ignores the return value of svc_proc_register(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later. Fix nfsd_proc_stat_init() to return the same type of pointer as svc_proc_register(), and fix up nfsd_net_init() to check that and fail the nfsd_net construction if it occurs. svc_proc_register() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsd_net construction codepath, so if this happens, return -ENOMEM.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:15:00 UTC" }, { "cve": "CVE-2023-54125", "url": "https://ubuntu.com/security/CVE-2023-54125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Return error for inconsistent extended attributes ntfs_read_ea is called when we want to read extended attributes. There are some sanity checks for the validity of the EAs. However, it fails to return a proper error code for the inconsistent attributes, which might lead to unpredicted memory accesses after return. [ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0 [ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199 [ 138.931132] [ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4 [ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 138.947327] Call Trace: [ 138.949557] [ 138.951539] dump_stack_lvl+0x4d/0x67 [ 138.956834] print_report+0x16f/0x4a6 [ 138.960798] ? ntfs_set_ea+0x453/0xbf0 [ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200 [ 138.969793] ? ntfs_set_ea+0x453/0xbf0 [ 138.973523] kasan_report+0xb8/0x140 [ 138.976740] ? ntfs_set_ea+0x453/0xbf0 [ 138.980578] __asan_store4+0x76/0xa0 [ 138.984669] ntfs_set_ea+0x453/0xbf0 [ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10 [ 138.993390] ? kernel_text_address+0xd3/0xe0 [ 138.998270] ? __kernel_text_address+0x16/0x50 [ 139.002121] ? unwind_get_return_address+0x3e/0x60 [ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 139.010177] ? arch_stack_walk+0xa2/0x100 [ 139.013657] ? filter_irq_stacks+0x27/0x80 [ 139.017018] ntfs_setxattr+0x405/0x440 [ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10 [ 139.026569] ? kvmalloc_node+0x2d/0x120 [ 139.030329] ? kasan_save_stack+0x41/0x60 [ 139.033883] ? kasan_save_stack+0x2a/0x60 [ 139.037338] ? kasan_set_track+0x29/0x40 [ 139.040163] ? kasan_save_alloc_info+0x1f/0x30 [ 139.043588] ? __kasan_kmalloc+0x8b/0xa0 [ 139.047255] ? __kmalloc_node+0x68/0x150 [ 139.051264] ? kvmalloc_node+0x2d/0x120 [ 139.055301] ? vmemdup_user+0x2b/0xa0 [ 139.058584] __vfs_setxattr+0x121/0x170 [ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10 [ 139.066282] __vfs_setxattr_noperm+0x97/0x300 [ 139.070061] __vfs_setxattr_locked+0x145/0x170 [ 139.073580] vfs_setxattr+0x137/0x2a0 [ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10 [ 139.080223] ? __kasan_check_write+0x18/0x20 [ 139.084234] do_setxattr+0xce/0x150 [ 139.087768] setxattr+0x126/0x140 [ 139.091250] ? __pfx_setxattr+0x10/0x10 [ 139.094948] ? __virt_addr_valid+0xcb/0x140 [ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330 [ 139.102688] ? debug_smp_processor_id+0x1b/0x30 [ 139.105985] ? kasan_quarantine_put+0x5b/0x190 [ 139.109980] ? putname+0x84/0xa0 [ 139.113886] ? __kasan_slab_free+0x11e/0x1b0 [ 139.117961] ? putname+0x84/0xa0 [ 139.121316] ? preempt_count_sub+0x1c/0xd0 [ 139.124427] ? __mnt_want_write+0xae/0x100 [ 139.127836] ? mnt_want_write+0x8f/0x150 [ 139.130954] path_setxattr+0x164/0x180 [ 139.133998] ? __pfx_path_setxattr+0x10/0x10 [ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10 [ 139.141299] ? debug_smp_processor_id+0x1b/0x30 [ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80 [ 139.150796] __x64_sys_setxattr+0x71/0x90 [ 139.155407] do_syscall_64+0x3f/0x90 [ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 139.163843] RIP: 0033:0x7f108cae4469 [ 139.166481] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc [ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469 [ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6 [ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618 [ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0 [ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15 ---truncated---", "cve_priority": "high", "cve_public_date": "2025-12-24 13:16:00 UTC" }, { "cve": "CVE-2026-31449", "url": "https://ubuntu.com/security/CVE-2026-31449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: validate p_idx bounds in ext4_ext_correct_indexes ext4_ext_correct_indexes() walks up the extent tree correcting index entries when the first extent in a leaf is modified. Before accessing path[k].p_idx->ei_block, there is no validation that p_idx falls within the valid range of index entries for that level. If the on-disk extent header contains a corrupted or crafted eh_entries value, p_idx can point past the end of the allocated buffer, causing a slab-out-of-bounds read. Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at both access sites: before the while loop and inside it. Return -EFSCORRUPTED if the index pointer is out of range, consistent with how other bounds violations are handled in the ext4 extent tree code.", "cve_priority": "high", "cve_public_date": "2026-04-22 14:16:00 UTC" }, { "cve": "CVE-2026-53245", "url": "https://ubuntu.com/security/CVE-2026-53245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53249", "url": "https://ubuntu.com/security/CVE-2026-53249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53252", "url": "https://ubuntu.com/security/CVE-2026-53252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53253", "url": "https://ubuntu.com/security/CVE-2026-53253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: reject short frames before parsing A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the packet type byte immediately and, for control packets, reads the control opcode and setup UUID-size byte before proving that those bytes are present. bnep_rx_control() also dereferences the control opcode without rejecting an empty control payload. Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL return gates each dereference. Split the control handler so the frame path can pass an opcode that has already been pulled, and keep the byte-buffer wrapper for extension control payloads. For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the setup payload. struct bnep_setup_conn_req carries destination and source service UUIDs after that byte, each uuid_size bytes, so the parser now documents that tuple explicitly instead of leaving the pull length as an opaque multiplication. Validation reproduced this kernel report: KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790 The buggy address belongs to the object at ffff88800c0f7908 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 1-byte region [ffff88800c0f7908, ffff88800c0f7909) Read of size 1 Call trace: dump_stack_lvl+0xb3/0x140 (?:?) print_address_description+0x57/0x3a0 (?:?) bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306) print_report+0xb9/0x2b0 (?:?) __virt_addr_valid+0x1ba/0x3a0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) kasan_addr_to_slab+0x21/0x60 (?:?) kasan_report+0xe0/0x110 (?:?) process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200) worker_thread+0x65c/0xe40 (?:?) __kthread_parkme+0x184/0x230 (?:?) kthread+0x35e/0x470 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) ret_from_fork+0x586/0x870 (?:?) __switch_to+0x74f/0xdc0 (?:?) ret_from_fork_asm+0x1a/0x30 (?:?)", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53254", "url": "https://ubuntu.com/security/CVE-2026-53254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: validate skb length in MCC handlers The RFCOMM MCC handlers cast skb->data to protocol-specific structs without validating skb->len first. A malicious remote device can send truncated MCC frames and trigger out-of-bounds reads in these handlers. Fix this by using skb_pull_data() to validate and access the required data before dereferencing it. rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows 1-byte RPN requests. Handle this by validating only the DLCI byte first, and validating the full struct only when len > 1.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53255", "url": "https://ubuntu.com/security/CVE-2026-53255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: validate advertising TLV before type checks tlv_data_is_valid() reads each advertising data field length from data[i], then inspects data[i + 1] for managed EIR types before checking that the current field still fits inside the supplied buffer. A malformed field whose length byte is the last byte of the buffer can therefore make the parser read one byte past the advertising data. KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING request reached that path: BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid() Read of size 1 Call trace: tlv_data_is_valid() add_advertising() hci_mgmt_cmd() hci_sock_sendmsg() Move the existing element-length check before any type-octet inspection so each non-empty element is proven to contain its type byte before the parser looks at data[i + 1].", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53256", "url": "https://ubuntu.com/security/CVE-2026-53256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock, but returns the selected listener after dropping that lock without taking a reference. rfcomm_connect_ind() then locks the listener, queues a child socket on it, and may notify it after unlocking it. The buggy scenario involves two paths, with each column showing the order within that path: rfcomm_connect_ind(): listener close: 1. Find parent in 1. close() enters rfcomm_get_sock_by_channel() rfcomm_sock_release(). 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown() without pinning parent. closes the listener. 3. Call lock_sock(parent) and 3. rfcomm_sock_kill() bt_accept_enqueue(parent, unlinks and puts parent. sk, true). 4. Read parent flags and may 4. parent can be freed. call sk_state_change(). If close wins the race, parent can be freed before rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the deferred-setup callback. Take a reference on the listener before leaving rfcomm_sk_list.lock. After lock_sock() succeeds, recheck that it is still in BT_LISTEN before queueing a child, cache the deferred-setup bit while the parent is locked, and drop the reference after the last parent use. KASAN reported a slab-use-after-free in lock_sock_nested() from rfcomm_connect_ind(), with the freeing stack going through rfcomm_sock_kill() and rfcomm_sock_release().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53263", "url": "https://ubuntu.com/security/CVE-2026-53263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 6lowpan: fix off-by-one in multicast context address compression The second memcpy in lowpan_iphc_mcast_ctx_addr_compress() uses &data[1] as destination and &ipaddr->s6_addr[11] as source, but both should be offset by one: &data[2] and &ipaddr->s6_addr[12] respectively. This off-by-one has two consequences: 1. data[1] is overwritten with s6_addr[11], corrupting the RIID field in the compressed multicast address 2. data[5] is never written, so uninitialized kernel stack memory is transmitted over the network via lowpan_push_hc_data(), leaking kernel stack contents The correct inline data layout must match what the decompression function lowpan_uncompress_multicast_ctx_daddr() expects: data[0..1] = s6_addr[1..2] (flags/scope + RIID) data[2..5] = s6_addr[12..15] (group ID) Also zero-initialize the data array as a defensive measure against similar bugs in the future.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53264", "url": "https://ubuntu.com/security/CVE-2026-53264", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: use RCU with deferred freeing for action lifecycle When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action. Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER: 0: mutex_lock() <-- holds the idr lock 0: rcu_read_lock() 0: p = idr_find(idr, index) <-- action p is valid (RCU protects IDR) 0: mutex_unlock() <-- releases the idr lock 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) <-- Action removed from IDR 1: mutex_unlock() <-- mutex released allowing us to delete the action 1: tcf_action_cleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- ouch, UAF p points to freed memory This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcu_head to tc_action used in the deferral and introducing a call_rcu() in the delete path to defer the final kfree(). Note: this is a revert of commit d7fb60b9cafb (\"net_sched: get rid of tcfa_rcu\") but also modernization/simplification to directly use kfree_rcu(). Let's illustrate the new restored code path: 0: rcu_read_lock() 1: refcount_dec_and_mutex_lock() <-- refcnt 1->0, mutex held 1: idr_remove(idr, index) 1: mutex_unlock() 1: call_rcu(&p->tcfa_rcu, tcf_action_rcu_free) <-- defer kfree after grace period 0: p = idr_find(idr, index) 0: refcount_inc_not_zero(&p->tcfa_refcnt) <-- fails, refcnt already 0 1: rcu_read_unlock() <-- release so freeing can run after grace period After CPU1 calls idr_remove(), the object is no longer reachable through the IDR. CPU0's subsequent idr_find() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53265", "url": "https://ubuntu.com/security/CVE-2026-53265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache policy smq: check allocation under invalidate lock commit 2d1f7b65f5de (\"dm cache policy smq: fix missing locks in invalidating cache blocks\") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section. That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check. This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again. Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53266", "url": "https://ubuntu.com/security/CVE-2026-53266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only safely reads the ARP header; it does not make the later sender hardware address range writable. If that range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits() maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable before reading the ARP header and before calling skb_store_bits().", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53268", "url": "https://ubuntu.com/security/CVE-2026-53268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack_irc: fix possible out-of-bounds read When parsing fails after we've matched the command string we should bail out instead of trying to match a different command. This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53269", "url": "https://ubuntu.com/security/CVE-2026-53269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: add mutex to guard hook reference counting As the synproxy infrastructure register netfilter hooks on-demand when a user adds the first iptables target or nftables expression, if done concurrently they can race each other. Introduce a mutex to serialize the refcount control blocks access from both frontends. While a per namespace mutex might be more efficient, it is not needed for target/expression like SYNPROXY.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53270", "url": "https://ubuntu.com/security/CVE-2026-53270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipvs: clear the svc scheduler ptr early on edit ip_vs_edit_service() while unbinding the old scheduler clears the svc->scheduler ptr after the scheduler module initiates RCU callbacks. This can cause packets to use the old scheduler at the time when svc->sched_data is already freed after RCU grace period. Fix it by clearing the ptr early in ip_vs_unbind_scheduler(), before the done_service method schedules any RCU callbacks. Also, if the new scheduler fails to initialize when replacing the old scheduler, try to restore the old scheduler while still returning the error code.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53273", "url": "https://ubuntu.com/security/CVE-2026-53273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tee: optee: prevent use-after-free when the client exits before the supplicant Commit 70b0d6b0a199 (\"tee: optee: Fix supplicant wait loop\") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request. If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free. Serialise access to the request with supp->mutex: * Hold supp->mutex in optee_supp_recv() and optee_supp_send() while looking up and touching the request. * Let optee_supp_thrd_req() notice that the client has terminated and signal optee_supp_send() accordingly. With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53275", "url": "https://ubuntu.com/security/CVE-2026-53275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix use-after-free when processing MLD queries When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskb_may_pull() calls, leading to a use-after-free [1]. Fix by copying the multicast group address when the packet is initially parsed. [1] BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118 Workqueue: mld mld_query_work Call Trace: dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120) print_address_description.constprop.0 (mm/kasan/report.c:378) print_report (mm/kasan/report.c:482) kasan_report (mm/kasan/report.c:595) __mld_query_work (net/ipv6/mcast.c:1512) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) [...] Freed by task 118: kasan_save_stack (mm/kasan/common.c:57) kasan_save_track (mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:584) __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskb_expand_head (net/core/skbuff.c:2335) __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4)) __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1)) mld_query_work (net/ipv6/mcast.c:1563) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-52948", "url": "https://ubuntu.com/security/CVE-2026-52948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-52910", "url": "https://ubuntu.com/security/CVE-2026-52910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new one while another thread is sending a UDP packet to the group. The reuseport prog is freed by sk_reuseport_prog_free(). bpf_prog_put() is called for \"e\"BPF prog to destruct through multiple stages while cBPF prog is freed immediately by bpf_release_orig_filter() and bpf_prog_free(). If a reuseport prog is detached from the setsockopt() path (reuseport_attach_prog() or reuseport_detach_prog()), sk_reuseport_prog_free() is called without waiting for RCU readers to complete, resulting in various bugs. Let's defer freeing the reuseport cBPF prog after one RCU grace period. Note \"e\"BPF prog is safe as is unless the fast path starts to touch fields destroyed in bpf_prog_put_deferred() and __bpf_prog_put_noref(). [0]: BUG: KASAN: vmalloc-out-of-bounds in reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 Read of size 4 at addr ffffc9000051e004 by task slowme/10208 CPU: 6 UID: 1000 PID: 10208 Comm: slowme Not tainted 7.0.0-geb7ac95ff75e #32 PREEMPT(full) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 reuseport_select_sock+0xedc/0x1220 net/core/sock_reuseport.c:596 udp4_lib_lookup2+0x3bc/0x950 net/ipv4/udp.c:495 __udp4_lib_lookup+0x768/0xe20 net/ipv4/udp.c:723 __udp4_lib_lookup_skb+0x297/0x390 net/ipv4/udp.c:752 __udp4_lib_rcv+0x1312/0x2620 net/ipv4/udp.c:2752 ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6181 [inline] __netif_receive_skb net/core/dev.c:6294 [inline] process_backlog+0xaa4/0x1960 net/core/dev.c:6645 __napi_poll+0xae/0x340 net/core/dev.c:7709 napi_poll net/core/dev.c:7772 [inline] net_rx_action+0x5d7/0xf50 net/core/dev.c:7929 handle_softirqs+0x22b/0x870 kernel/softirq.c:622 do_softirq+0x76/0xd0 kernel/softirq.c:523 __local_bh_enable_ip+0xf8/0x130 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline] __dev_queue_xmit+0x1dd7/0x3710 net/core/dev.c:4890 neigh_output include/net/neighbour.h:556 [inline] ip_finish_output2+0xca9/0x1070 net/ipv4/ip_output.c:237 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip_output+0x29f/0x450 net/ipv4/ip_output.c:438 ip_send_skb+0x45/0xc0 net/ipv4/ip_output.c:1508 udp_send_skb+0xb04/0x1510 net/ipv4/udp.c:1195 udp_sendmsg+0x1a71/0x2350 net/ipv4/udp.c:1485 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] __sys_sendto+0x554/0x680 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline] __se_sys_sendto net/socket.c:2209 [inline] __x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x160/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x415a2d Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6bc31e41e8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f6bc31e4cdc RCX: 0000000000415a2d RDX: 0000000000000001 RSI: 00007f6bc31e421f RDI: 0000000000000003 RBP: 00007f6bc31e4240 R08: 00007f6bc31e4220 R09: 0000000000000010 R10: 0000000000000000 R11: ---truncated---", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-52923", "url": "https://ubuntu.com/security/CVE-2026-52923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipc: limit next_id allocation to the valid ID range The checkpoint/restore sysctl path can request the next SysV IPC id through ids->next_id. ipc_idr_alloc() currently forwards that request to idr_alloc() with an open-ended upper bound. If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object. The bug is in ipc_idr_alloc() in the checkpoint/restore path. 1. ids->next_id is passed to: idr_alloc(&ids->ipcs_idr, new, ipcid_to_idx(next_id), 0, ...) 2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idr_alloc() can spill past ipc_mni and allocate an entry beyond the valid IPC id range. 3. The new object id is still encoded with the narrower SysV IPC index width: new->id = (new->seq << ipcmni_seq_shift()) + idx 4. Later removal goes through ipc_rmid(), which uses: ipcid_to_idx(ipcp->id) That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index. 5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer. 6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory. Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2025-39929", "url": "https://ubuntu.com/security/CVE-2025-39929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()", "cve_priority": "medium", "cve_public_date": "2025-10-04 08:15:00 UTC" }, { "cve": "CVE-2026-45852", "url": "https://ubuntu.com/security/CVE-2026-45852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. If copy_to_user() fails, the function calls rxe_queue_cleanup() to free the queue, but leaves the now-invalid pointer in 'srq->rq.queue'. The caller of rxe_srq_from_init() (rxe_create_srq) eventually calls rxe_srq_cleanup() upon receiving the error, which triggers a second rxe_queue_cleanup() on the same memory, leading to a double free. The call trace looks like this: kmem_cache_free+0x.../0x... rxe_queue_cleanup+0x1a/0x30 [rdma_rxe] rxe_srq_cleanup+0x42/0x60 [rdma_rxe] rxe_elem_release+0x31/0x70 [rdma_rxe] rxe_create_srq+0x12b/0x1a0 [rdma_rxe] ib_create_srq_user+0x9a/0x150 [ib_core] Fix this by moving 'srq->rq.queue = q' after copy_to_user.", "cve_priority": "high", "cve_public_date": "2026-05-27 14:16:00 UTC" }, { "cve": "CVE-2025-39863", "url": "https://ubuntu.com/security/CVE-2025-39863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions: 1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync(). 2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs. The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread. Scenario 1: Freed before the worker is scheduled The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE Scenario 2: Freed after the worker is scheduled The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario: CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ | To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.", "cve_priority": "high", "cve_public_date": "2025-09-19 16:15:00 UTC" }, { "cve": "CVE-2026-52934", "url": "https://ubuntu.com/security/CVE-2026-52934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-52913", "url": "https://ubuntu.com/security/CVE-2026-52913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: stop OGMv2 on disabled interface When a batadv_hard_iface is disabled, its mesh_iface pointer is set to NULL. However, batadv_v_ogm_send_meshif() may still dispatch OGMs via batadv_v_ogm_queue_on_if() for interfaces that have since lost their mesh_iface association. This results in a NULL pointer dereference when batadv_v_ogm_queue_on_if() unconditionally calls netdev_priv() on the now NULL hard_iface->mesh_iface to retrieve the batadv_priv. It is necessary to ensure that the batadv_v_ogm_queue_on_if() checks that it is using the same mesh_iface for which batadv_v_ogm_send_meshif() was called.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-46321", "url": "https://ubuntu.com/security/CVE-2026-46321", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tun: free page on short-frame rejection in tun_xdp_one() tun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without freeing the page that vhost_net_build_xdp() allocated for it. tun_sendmsg() discards that -EINVAL and still returns total_len, so vhost_tx_batch() takes the success path and never frees the page; each short frame in a batch leaks one page-frag chunk. A local process that can open /dev/net/tun and /dev/vhost-net can hit this path: it attaches a tun/tap device as the vhost-net backend and feeds TX descriptors whose length minus the virtio-net header is below ETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a tight submission loop exhausts host memory and triggers an OOM panic. Free the page before returning -EINVAL, matching the XDP-program error path in the same function.", "cve_priority": "medium", "cve_public_date": "2026-06-09 13:16:00 UTC" }, { "cve": "CVE-2026-52927", "url": "https://ubuntu.com/security/CVE-2026-52927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43219", "url": "https://ubuntu.com/security/CVE-2026-43219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-43064", "url": "https://ubuntu.com/security/CVE-2026-43064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix not releasing workqueue on .release() The workqueue associated with an DSA/IAA device is not released when the object is freed.", "cve_priority": "medium", "cve_public_date": "2026-05-05 16:16:00 UTC" }, { "cve": "CVE-2026-45930", "url": "https://ubuntu.com/security/CVE-2026-45930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp: ensure our nlmsg responses are initialised Syed Faraz Abrar (@farazsth98) from Zellic, and Pumpkin (@u1f383) from DEVCORE Research Team working with Trend Micro Zero Day Initiative report that a RTM_GETNEIGH will return uninitalised data in the pad bytes of the ndmsg data. Ensure we're initialising the netlink data to zero, in the link, addr and neigh response messages.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-53080", "url": "https://ubuntu.com/security/CVE-2026-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_fw: fix NULL dereference of \"old\" filters before change() Like pointed out by Sashiko [1], since commit ed76f5edccc9 (\"net: sched: protect filter_chain list with filter_chain_lock mutex\") TC filters are added to a shared block and published to datapath before their ->change() function is called. This is a problem for cls_fw: an invalid filter created with the \"old\" method can still classify some packets before it is destroyed by the validation logic added by Xiang. Therefore, insisting with repeated runs of the following script: # ip link add dev crash0 type dummy # ip link set dev crash0 up # mausezahn crash0 -c 100000 -P 10 \\ > -A 4.3.2.1 -B 1.2.3.4 -t udp \"dp=1234\" -q & # sleep 1 # tc qdisc add dev crash0 egress_block 1 clsact # tc filter add block 1 protocol ip prio 1 matchall \\ > action skbedit mark 65536 continue # tc filter add block 1 protocol ip prio 2 fw # ip link del dev crash0 can still make fw_classify() hit the WARN_ON() in [2]: WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399 Modules linked in: cls_fw(E) act_skbedit(E) CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full) Tainted: [E]=UNSIGNED_MODULE Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014 RIP: 0010:fw_classify+0x244/0x250 [cls_fw] Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 <0f> 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202 RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004 RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40 RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000 R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000 FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0 Call Trace: tcf_classify+0x17d/0x5c0 tc_run+0x9d/0x150 __dev_queue_xmit+0x2ab/0x14d0 ip_finish_output2+0x340/0x8f0 ip_output+0xa4/0x250 raw_sendmsg+0x147d/0x14b0 __sys_sendto+0x1cc/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x126/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fca40e822ba Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003 RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000 irq event stamp: 1045778 hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60 hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60 softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260 softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0 Then, because of the value in the packet's mark, dereference on 'q->handle' with NULL 'q' occurs: BUG: kernel NULL pointer dereference, address: 0000000000000038 [...] RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw] [...] Skip \"old-style\" classification on shared blocks, so that the NULL dereference is fixed and WARN_ON() is not hit anymore in the short lifetime of invalid cls_fw \"old-style\" filters. [1] https://sashiko.dev/#/patchset/2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53354", "url": "https://ubuntu.com/security/CVE-2026-53354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Mitigate TLBI errata on various Arm CPUs A number of CPUs developed by Arm suffer from errata whereby a broadcast TLBI;DSB sequence may complete before the global observation of writes which are translated by an affected TLB entry. These errata ONLY affect the completion of memory accesses which have been translated by an invalidated TLB entry, and these errata DO NOT affect the actual invalidation of TLB entries. TLB entries are removed correctly. This issue has been assigned CVE ID CVE-2025-10263. To mitigate this issue, Arm recommends that software follows any affected TLBI;DSB sequence with an additional TLBI;DSB, which will ensure that all memory write effects affected by the first TLBI have been globally observed. The additional TLBI can use any operation that is broadcast to affected CPUs, and the additional DSB can use any option that is sufficient to complete the additional TLBI. The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate the issue. Enable this workaround for affected CPUs, and update the silicon errata documentation accordingly. Note that due to the manner in which Arm develops IP and tracks errata, some CPUs share a common erratum number.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-63888", "url": "https://ubuntu.com/security/CVE-2026-63888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd() Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c (\"iscsi-target: Add iSCSI fabric support for target v4.1\"): 1) DataDigest CRC buffer overread (4 bytes past text_in). text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf(): if (conn->conn_ops->DataDigest) { ... rx_size += ISCSI_CRC_LEN; } ... if (conn->conn_ops->DataDigest) { data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL); iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C. Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc(). 2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop. On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap: kfree(text_in); return 0; cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does kfree(cmd->text_in_ptr); cmd->text_in_ptr = NULL; freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives. On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats: BUG: KASAN: double-free in iscsit_setup_text_cmd+0x?? BUG: KASAN: double-free in iscsit_release_cmd+0x?? showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist. Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together. Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63887", "url": "https://ubuntu.com/security/CVE-2026-63887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf iscsi_encode_text_output() concatenates \"key=value\\0\" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity: \t*length += sprintf(output_buf, \"%s=%s\", er->key, er->value); \t*length += 1; \toutput_buf = textbuf + *length; The 8192-byte ceiling at iscsi_target_check_login_request() bounds the *input* Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte \"a=b\\0\" pairs, each unknown key expanding to a 16-byte \"a=NotUnderstood\\0\" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab. The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53355", "url": "https://ubuntu.com/security/CVE-2026-53355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: rds: clear i_sends on setup unwind The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released. When rds_ib_setup_qp() fails after allocating i_sends but before allocating i_recvs, the sends_out path frees i_sends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation. Clear i_sends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-53186", "url": "https://ubuntu.com/security/CVE-2026-53186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRP_RSP with SRP_RSP_FLAG_SNSVALID set and a large resp_data_len. The receive buffer is allocated at the target-chosen max_ti_iu_len, so the source of the sense copy lands past the bytes actually received; with resp_data_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults. Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->byte_len; this brings ib_srp into line with them.", "cve_priority": "high", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53216", "url": "https://ubuntu.com/security/CVE-2026-53216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-63912", "url": "https://ubuntu.com/security/CVE-2026-63912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: esp: restore combined single-frag length gate The ESP out-of-place fast path appends the trailer in esp_output_head() before esp_output_tail() allocates the destination page frag. The head-side gate currently checks skb->data_len and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->data_len. Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skb_page_frag_refill() may fall back to a single page while the destination sg still spans the combined skb->data_len. Restore this combined-length page gate for both IPv4 and IPv6.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63922", "url": "https://ubuntu.com/security/CVE-2026-63922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh after handling HAO option ip6_parse_tlv() caches skb_network_header(skb) in nh while walking IPv6 TLVs. ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can move the skb head and invalidate the cached network header pointer. Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs are parsed from the current skb head. This matches the existing pattern used in ip6_parse_tlv() after helpers that can modify skb header storage.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63924", "url": "https://ubuntu.com/security/CVE-2026-63924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo() ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers. Let's recompute nh pointer to make sure any change won't mess things up.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64091", "url": "https://ubuntu.com/security/CVE-2026-64091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: fix TOCTOU race for reported vlans The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshif_vlan_list_lock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list. But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated. It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.", "cve_priority": "high", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63984", "url": "https://ubuntu.com/security/CVE-2026-63984", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63992", "url": "https://ubuntu.com/security/CVE-2026-63992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: do not assume transport header in iptunnel_pmtud_check_icmp() In some cases, iptunnel_pmtud_check_icmp() can be called while skb transport header is not set. This triggers an out-of-bound access, because (typeof(skb->transport_header))~0U is 65535. Access the icmp header based on IPv4 network header, after making sure icmp->type is present in skb linear part. Note that iptunnel_pmtud_check_icmpv6()) is fine.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63993", "url": "https://ubuntu.com/security/CVE-2026-63993", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu() skb_tunnel_check_pmtu() can change skb->head. Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF. Use instead ip_hdr(skb) as done in drivers/net/bareudp.c and drivers/net/geneve.c. Found by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-63994", "url": "https://ubuntu.com/security/CVE-2026-63994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tunnels: load network headers after skb_cow() in iptunnel_pmtud_build_icmp[v6]() Sashiko found that iptunnel_pmtud_build_icmp() and iptunnel_pmtud_build_icmpv6() were caching ip_hdr() and ipv6_hdr() before an skb_cow() call which can reallocate skb->head. Fix this possible UAF by initializing the local variables after the skb_cow() call. Remove skb_reset_network_header() calls which were not needed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-64007", "url": "https://ubuntu.com/security/CVE-2026-64007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: synproxy: refresh tcphdr after skb_ensure_writable synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer. Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale: caller (ipv[46]_synproxy_hook) th = skb_header_pointer(skb, ..., &_tcph) synproxy_tstamp_adjust(skb, protoff, th, ...) skb_ensure_writable(skb, optend) pskb_expand_head() /* kfree(old skb->head) */ ... inet_proto_csum_replace4(&th->check, ...) /* writes into freed head, or into the caller's stack copy leaving the on-wire checksum stale */ The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload. Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.", "cve_priority": "medium", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53221", "url": "https://ubuntu.com/security/CVE-2026-53221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup() In vti6_tnl_lookup(), when an exact match for a tunnel fails, the code falls back to searching for wildcard tunnels: - Tunnels matching the packet's local address, with any remote address wildcard remote). - Tunnels matching the packet's remote address, with any local address (wildcard local). However, vti6 stores all these different types of tunnels in the same hash table (ip6n->tnls_r_l) prone to hash collisions. The bug is that the fallback search loops in vti6_tnl_lookup() were missing checks to ensure that the candidate tunnel actually has a wildcard address.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * jammy/linux-kvm: 5.15.0-1109.114 -proposed tracker (LP: #2165588)", "", " [ Ubuntu: 5.15.0-198.208 ]", "", " * jammy/linux: 5.15.0-198.208 -proposed tracker (LP: #2166457)", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2026.08.31)", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192)", " - Input: ims-pcu - fix logic error in packet reset", " - KVM: VMX: Make vmread_error_trampoline() uncallable from C code", " - mtd: mtdswap: remove debugfs stats file on teardown", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - RDMA/siw: Only check attrs->cap.max_send_wr in siw_create_qp", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ata: sata_dwc_460ex: remove variable num_processed", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - powerpc/time: Fix sparse warnings", " - powerpc: remove the last remnants of cputime_t", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - ASoC: bt-sco: fix bt-sco-pcm-wb dai widget don't connect to the endpoint", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - hwmon: (occ) Add sysfs entry for IPS (Idle Power Saver) status", " - hwmon: (occ) Add sysfs entry for OCC mode", " - hwmon: (occ) Add sysfs entries for additional extended status bits", " - hwmon: (occ) Delay hwmon registration until user request", " - net: dpaa2-eth: assign priv->mac after dpaa2_mac_connect() call", " - wifi: mac80211: recalculate TIM when a station enters power save", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: stmmac: add tc flower filter for EtherType matching", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - raw: use more conventional iterators", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - x86/boot/compressed: Disable jump tables", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - proc: Fix broken error paths for namespace links", " - ice: use READ_ONCE() to access cached PHC time", " - raw: remove unused variables from raw6_icmp_error()", " - raw: fix a typo in raw_icmp_error()", " - media: uvcvideo: Implement dual stream quirk to fix loss of usb packets", " - media: uvcvideo: Fix sequence number when no EOF", " - HID: logitech-dj: Standardise hid_report_enum variable nomenclature", " - HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB", " write", " - HID: logitech-dj: fix wrong detection of bad DJ_SHORT output report", " - net: qrtr: ns: Raise node count limit to 512", " - dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA", " - ASoC: max98095: fix missing IS_ERR() before PTR_ERR() on mclk lookup", " - ASoC: max98090: fix missing IS_ERR() before PTR_ERR() on mclk lookup", " - phy: zynqmp: Allow variation in refclk rate", " - phy-zynqmp: Postpone getting clock rate until actually needed", " - phy: zynqmp: fix clock error handling in xpsgtr_phy_init()", " - phy: zynqmp: fix runtime PM leak on probe allocation failure", " - drm/mediatek: Check CRTC state before freeing", " - assoc_array: trim the final shortcut word using the current chunk end", " - smb: client: fix buffer leaks in SMB1 read and write", " - net: bridge: mrp: fix Option TLV length in MRP_Test frames", " - hwmon: (adt7470) Fix fans stuck in manual mode on I2C errors", " - hwmon: (adt7470) Fix cache updated before hardware write on I2C error", " - hwmon: (adt7470) Fix temperature alarm logic in hwmon_temp_read()", " - hwmon: (adt7470) Fix swapped PWM3 and PWM4 auto mode masks", " - hwmon: (adt7470) Use cached PWM frequency value", " - hwmon: (adt7470) Fix PWM auto temp state array and bounds check", " - powerpc/boot: Fix simpleboot CPU node lookup check", " - powerpc/boot: Fix treeboot-currituck CPU node lookup check", " - powerpc/boot: Fix treeboot-akebono CPU node lookup check", " - wifi: mac80211: validate individual TWT params before driver setup", " - hwmon: (pmbus) Fix return value from pmbus_update_byte_data()", " - net: phylink: put link_gpio if phylink_create fails", " - scsi: zfcp: Fix memory leak during adapter release by destroying", " gid_pn_req", " - net: sxgbe: check descriptor ring allocation failures", " - can: isotp: check register_netdevice_notifier() error in module init", " - tracing/mmiotrace: Reset dropped_count in mmio_reset_data()", " - octeontx2-pf: Set correct sequence for carrier off and tx queue stop", " - pinctrl: bm1880: add missing select GENERIC_PINCONF", " - mm/percpu-km: fix bitmap overflow and accounting in pcpu_create_chunk()", " - sctp: validate Adaptation Indication parameter length", " - audit: fix potential integer overflow in audit_log_n_string()", " - bpf: lwt: Fix dst reference leak on reroute failure", " - ALSA: lx6464es: fix period byte count for 16-bit streams", " - ALSA: pcm: wake linked drain waiters on unlink", " - ASoC: tas2562: fix DVC coefficient write order", " - ASoC: tas2562: fix broken entries in the volume lookup table", " - dmaengine: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+", " - e1000: fix memory leak in e1000_probe()", " - ipvs: do not propagate one-packet flag to synced conns", " - net: ipv6: clear suppressed fib6 rule result", " - powerpc/ps3: Fix map failure path in dma_ioc0_map_pages()", " - vxlan: re-fetch eth header after route_shortcircuit()", " - vxlan: unclone skb head before modifying eth header in", " route_shortcircuit()", " - tracing/filters: Fix false positive match in regex_match_full()", " - selftests/clone3: fix wild pointer access of getline due to missing init", " - sctp: reject stale cookies with mismatched verification tags", " - hwmon: (npcm750-pwm-fan): stop fan timer on device detach", " - i2c: amd-mp2: Unregister callback on adapter add failure", " - cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init()", " - s390/dasd: Fix potential NULL pointer dereference", " - phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask", " - phy: zynqmp: use read-modify-write for SERDES scrambler bypass", " - phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB", " - can: c_can: c_can_chip_config(): keep controller in init mode until", " bittiming is configured", " - can: j1939: transport: j1939_session_fresh_new(): initialize receive", " buffer", " - can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in", " kvaser_usb_hydra_get_busparams()", " - can: softing: fw_parse(): validate firmware record spans", " - drm/amdgpu: restore UMD profile pstate after runtime resume", " - drm/amdgpu: cap GTT size to physical RAM on APUs", " - HID: logitech-dj: Fix maxfield check in DJ short report validation", " - net: openvswitch: fix skb leak on flow key update failure during", " recirculation", " - mount: honour SB_NOUSER in the new mount API", " - s390/zcrypt: Fix missing mem scrub at clear key import in", " cca_clr2cipherkey()", " - nfs4: take a reference on the nfs_client when running FREE_STATEID", " - NFS: Pin the 'struct nfs_server' during a FREE_STATEID call", " - ARM: npcm: Fix OF node refcount leaks in SMP setup", " - bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitor", " - bpf: Preserve pointer state for commuted arithmetic", " - net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in", " smc_llc_event_handler()", " - net/sched: cls_route: fix fastmap use-after-free on filter", " - net: hisilicon: hix5hd2_gmac: remove redundant NAPI delete", " - net/mlx5: fw_tracer, return NULL on create error", " - counter: microchip-tcb-capture: Fix DT channel validation", " - vhost/vdpa: reject overflowing PA map page counts on 32-bit", " - udp: fix potential use-after-free in tunnel segmentation", " - net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter", " - net/openvswitch: check Ethernet header length in key_extract()", " - selftests/ftrace: Add test case for GRP/ only input", " - selftests/ftrace: refactor eprobes test to fix argument checks", " - bnxt_en: Do not set EOP on RX AGG BDs on 5760X chips", " - bnxt_en: Disable EOP for TPA on all chips to prevent data corruption", " - bnxt_en: Fix PTP PPS setting bug", " - sctp: fix addip_serial increment on ASCONF_ACK allocation failure", " - tcp: fix TFO max_qlen accounting across reuseport migration", " - net/ncsi: fix heap OOB read in NCSI_CMD_SEND_CMD payload length", " - net: prestera: validate firmware header length", " - net: remove WARN_ON_ONCE() from sk_mc_loop()", " - net/smc: fix TOCTOU race between smc_listen_out() and listener close", " - net: qrtr: ns: Raise lookup limit to 128", " - net: thunderbolt: Tear down DMA paths before stopping the rings", " - ata: pata_sl82c105: fix bridge revision use-after-free", " - sctp: clear control chunk transport if it is being removed", " - tls: don't abort the connection on signal-interrupted sends", " - hwmon: (corsair-psu) fix possible out-of-bounds access on missing string", " termination", " - spi: spi-fsl-dspi: Avoid setup_accel logic for DMA transfers", " - Input: evdev - sanitize event type index when fetching event masks", " - ALSA: usb-audio: fix OOB write on Type II inbound URBs", " - usb: atm: cxacru: properly kill rcv_urb on error in cxacru_cm()", " - thunderbolt: icm: Preserve USB4 proxy data-valid bit", " - usb: cdnsp: fix incorrect endian conversions for APB timeout register", " - usb: gadget: f_ncm: Use unsigned int for ndp_index", " - ima: fix out-of-bounds read in xattr_verify()", " - ipvs: add totalconns for dest", " - ipvs: properly update the overload flag on dest edit", " - ipvs: clear IPv4 options after rebasing tunnel ICMP errors", " - net/packet: reset the MAC header on the packet-socket transmit path", " - net: openvswitch: reallocate update replies for mismatched IDs", " - net: octeontx2-pf: Fix UB in shift operation", " - net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header", " - netfilter: ebt_nflog: pin the NFLOG backend", " - net: bridge: mrp: fix uninitialised bytes on the wire", " - vt: add permission check for KDSKBMETA ioctl", " - vt: stabilize tty reference in kbd_keycode with tty_port_tty_get", " - Input: evdev - fix information leak in evdev_pass_values()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - futex: Prevent robust futex exit race some more", " - pinctrl: renesas: rzg2l: Use -ENOTSUPP instead of -EOPNOTSUPP", " - fscrypt: Replace mk_users keyring with simple list", " - ipv4: Fix fib_nlmsg_size() for RTA_VIA nexthops", " - ipv4: fix use-after-free in fib_nhc_update_mtu()", " - serial: 8250_dma: Clear stale RX state on shutdown", " - staging: rtl8723bs: fix OOB read in rtw_get_wpa_ie()", " - staging: rtl8723bs: fix OOB read in WMM_param_handler()", " - staging: rtl8723bs: fix missing shared-key auth challenge length check", " - staging: rtl8723bs: validate monitor transmit frame lengths", " - misc: fastrpc: fix channel ctx ref leak when session alloc fails", " - misc: fastrpc: fix memory leak in fastrpc_channel_ctx_free", " - ALSA: usx2y: bound the hwdep mmap fault offset", " - tracing: Fix race between update_event_fields and, event_define_fields", " - fbdev: bitblit: bound-check glyph index in bit_cursor()", " - ipv6: prevent in6_dev_get() from resurrecting inet6_dev", " - netfilter: bridge: release template ct on non-IP path", " - net: atlantic: free RX pages of consumed but not refilled buffers", " - net/sched: act_gact, act_police: range check the fallback control action", " - xdp: reject clones that overrun skb_shared_info tailroom", " - vxlan: do not arm the ageing timer on a device that is down", " - vsock/virtio: read virtqueues under worker locks", " - vsock/virtio: avoid refilling the RX queue after teardown", " - vhost: reset the vring metadata cache on vring reconfiguration", " - tipc: read le->link under the node lock in tipc_node_link_down()", " - Revert \"thermal/drivers/hwmon: Cleanup coding style a bit\"", " - ipv6: fix Route Information option length validation", " - ip6_tunnel: clear skb2->cb[] in ip6ip6_err()", " - bpf, sockmap: Fix sk_redir use-after-free in send verdict", " - scsi: scsi_debug: Negate wrapped memcmp() result", " - sctp: keep chunk->transport in step with the list it is queued on", " - sctp: fix use-after-free of cached ASCONF chunk", " - sctp: clear new_transport when removing a peer", " - thunderbolt: Bound the DROM dual link port number before indexing", " sw->ports", " - Linux 5.15.216", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64582", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74468", " - gpio: pch: use raw_spinlock_t for the register lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74482", " - mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74443", " - drm/vmwgfx: bound DMA command body size against suffix pointer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74444", " - drm/vmwgfx: validate DRAW_PRIMITIVES header size before division", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74453", " - drm/vc4: Zero the tile state data array before each BIN job", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74455", " - can: peak_usb: validate uCAN receive record lengths", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74456", " - can: peak_usb: peak_usb_start(): fix double free of transfer buffer on", " URB submit error", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74457", " - can: peak_usb: add bounds check for USB channel index", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74458", " - can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received", " command extents", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74459", " - can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB", " resubmit failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74460", " - can: ems_usb: validate CPC message lengths", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74461", " - i2c: imx: Cancel hrtimer before clearing slave pointer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74463", " - i2c: jz4780: Cache host clock rate at probe to prevent CCF prepare_lock", " deadlock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74464", " - net: openvswitch: fix skb leak on flow key update failure during ct", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74465", " - net: openvswitch: fix potential UAF on meter attach failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68451", " - s390/zcrypt: Validate length for CCA ECC private key requests", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68452", " - s390/zcrypt: Validate length for CCA AES cipher key requests", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74467", " - s390/qeth: Check CAP_NET_ADMIN for private ioctls", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74469", " - sctp: prevent peer transport count overflow", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74471", " - tracing: Check return value of __register_event() in", " trace_module_add_events()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74473", " - vxlan: use pskb_network_may_pull() in route_shortcircuit()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74475", " - vxlan: use neigh_ha_snapshot() in route_shortcircuit()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74478", " - um: vector: fix use-after-free in vector_mmsg_rx()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74480", " - net: bridge: stop fast-leave after deleting a port group", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74481", " - mm/page_reporting: use system_freezable_wq to fix UAF during suspend", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74485", " - binfmt_misc: reject a flag character as the field delimiter", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74488", " - wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74490", " - tipc: avoid use-after-free in poll trace queue dumps", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74492", " - netfilter: ipset: do not update comments from kernel-side hash adds", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74493", " - net/smc: fix socket use-after-free during link group termination", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74495", " - igbvf: Fix leak in TX DMA error cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74497", " - ALSA: usb-audio: Clamp frame size in implicit-feedback mode", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74498", " - ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74499", " - ALSA: usb-audio: fix OOB write in snd_usbmidi_akai_output()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74505", " - ALSA: 6fire: Fix UAF at error handling during probe", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74507", " - Bluetooth: HIDP: validate numbered report payloads", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74508", " - Bluetooth: HIDP: reject frames without a transaction header", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74512", " - audit: fix potential use-after-free in audit_del_rule()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74518", " - mm/hugetlb: fix list corruption in allocate_file_region_entries()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74519", " - pinctrl: devicetree: don't free uninitialized dev_name on error path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64563", " - rhashtable: clear stale iter->p on table restart", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74523", " - qede: sync udp_tunnel ports outside qede_lock in the recovery path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74525", " - net: sxgbe: free TX rings on RX allocation failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74540", " - Bluetooth: L2CAP: fix UAF in l2cap_le_connect_rsp", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74546", " - hwmon: (adt7470) Fix divide-by-zero TOCTOU crash in fan speed read", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74547", " - hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74548", " - forcedeth: fix UAF of txrx_stats in nv_remove", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74549", " - hwmon: (nct6775-core) Prevent access to unsupported weight registers", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74556", " - scsi: libiscsi_tcp: Bound SCSI Response data segment to the connection", " buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74557", " - scsi: libiscsi: Fix stale-data leak into the SCSI sense buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74563", " - rds: tcp: hold the RCU lock across ipv6_chk_addr() in", " rds_tcp_laddr_check()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68322", " - rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74579", " - netfilter: nft_payload: fix mask build for partial field offload", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74564", " - netfilter: xt_hashlimit: validate hashtable supports", " XT_HASHLIMIT_RATE_MATCH", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74566", " - keys: make keyring key-chunk byte order agree with", " keyring_diff_objects()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74567", " - keys: fix out-of-bounds read in keyring_get_key_chunk()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74569", " - netfilter: nf_conntrack_sip: widen NAT rewrite delta to s32 in", " sip_help_tcp()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-43491", " - net: qrtr: ns: Limit the maximum server registration per node", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-74577", " - net: mpls: initialize rtm_tos in mpls_getroute()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64543", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72123", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-72019", " - macsec: don't read an unset MAC header in macsec_encrypt()", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-52977", " - futex: Prevent lockup in requeue-PI during signal/ timeout wakeup", " * Jammy update: v5.15.216 upstream stable release (LP: #2165192) //", " CVE-2026-64535", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " * ice: E810 interface fails to initialize (ice_init_hw failed: -5) during", " NVM read (LP: #2163508)", " - ice: acquire NVM lock around each flash read", " * seccomp filter leak in bpf_jit due to unreaped zombie process", " (LP: #2164699)", " - seccomp: release task filters when the task exits", " * 5.15 kernel selftest srv6_end_dt6_l3vpn_test.sh failure (LP: #1961566)", " - SAUCE: selftest/net: skip srv6_end_dt6_l3vpn_test.sh if iproute2 too old", " * 5.15 kernel selftest srv6_end_dt4_l3vpn_test.sh failure (LP: #1956562)", " - SAUCE: selftest/net: skip srv6_end_dt4_l3vpn_test.sh if iproute2 too old", " * [UBUNTU 22.04] s390/topology: Use zero-based numbering (LP: #2164516)", " - s390/topology: Use zero-based numbering for containing entities", " * mount08 from ubuntu_ltp_syscalls failed - TFAIL: mount(/proc/139835/fd/4)", " succeeded (LP: #2137199)", " - proc: proc_readfd() -> proc_fd_iterate()", " - proc: proc_readfdinfo() -> proc_fdinfo_iterate()", " - proc: add proc_splice_unmountable()", " - proc: block mounting on top of /proc//map_files/*", " - proc: block mounting on top of /proc//fd/*", " - proc: block mounting on top of /proc//fdinfo/*", " * Jammy update: v5.15.215 upstream stable release (LP: #2165170)", " - Linux 5.15.215", " * Jammy update: v5.15.215 upstream stable release (LP: #2165170) //", " CVE-2026-68480", " - x86/bugs: Make Safe-RET robust against interrupt injection", " * Jammy update: v5.15.214 upstream stable release (LP: #2165166)", " - Linux 5.15.214", " * Jammy update: v5.15.213 upstream stable release (LP: #2165125)", " - Linux 5.15.213", " * Jammy update: v5.15.213 upstream stable release (LP: #2165125) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124)", " - nfc: llcp: protect nfc_llcp_sock_unlink() calls", " - net/sched: act_pedit: use NLA_POLICY for parsing 'ex' keys", " - dma-buf: remove unused dma-fence-unwrap.c (stable/linux-5.15.y only)", " - slimbus: qcom-ngd-ctrl: Fix up platform_driver registration", " - slimbus: qcom-ngd-ctrl: Fix probe error path ordering", " - slimbus: qcom-ngd-ctrl: Correct PDR and SSR cleanup ownership", " - slimbus: Convert to platform remove callback returning void", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - skmsg: convert struct sk_msg_sg::copy to a bitmap", " - f2fs: fix to detect corrupted meta ino", " - f2fs: adjust zone capacity when considering valid block count", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: fix listxattr handling of corrupted xattr entries", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - PCI: altera: Do not dispose parent IRQ mapping", " - PCI: host-common: Request bus reassignment when not probe-only", " - virtio-mmio: fix device release warning on module unload", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - fuse: fix device node leak in cuse_process_init_reply()", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - tools/mm/slabinfo: fix total_objects attribute name", " - net: dsa: tag_ksz: do not rely on skb_mac_header() in TX paths", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - [Config] Remove CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - afs: Fix further netns teardown to cancel the preallocation charger", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - thermal: hwmon: Fix critical temperature attribute removal", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - media: rockchip: rga: fix too small buffer size", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - PM: sleep: Use complete() in device_pm_sleep_init()", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Fix UAF in strset__add_str()", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ARM: imx3: Fix CCM node reference leak", " - ARM: imx31: Fix IIM mapping leak in revision check", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - mm/fake-numa: fix under-allocation detection in uniform split", " - lib/test_meminit: use && for bools", " - bpftool: Use libbpf error code for flow dissector query", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Introduce SNDRV_SEQ_IOCTL_USER_PVERSION ioctl", " - ALSA: seq: Add UMP support", " - [Config] Disable CONFIG_SND_SEQ_UMP=n", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - hwspinlock: qcom: avoid uninitialized struct members", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - vduse: Requeue failed read to send_list head", " - tools/virtio: check mmap return value in vringh_test", " - bonding: 3ad: fix mux port state on oper down", " - selftests/bpf: Fix bpf_iter/task_vma test", " - s390/process: Fix kernel thread function pointer type", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - crypto: rng - Free default RNG on module exit", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - netfilter: nf_conncount: callers must hold rcu read lock", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: zero-initialize the fib lookup flow struct", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - veth: fix NAPI leak in XDP enable error path", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - qede: fix out-of-bounds check for cqe->len_list[]", " - rtnetlink: change nlk->cb_mutex role", " - rtnetlink: add RTNL_FLAG_DUMP_UNLOCKED flag", " - inet: allow ip_valid_fib_dump_req() to be called with RTNL or RCU", " - ipv6: remove RTNL protection from inet6_dump_fib()", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - virtio_net: disable cb when NAPI is busy-polled", " - cxgb4: Fix decode strings dump for T6 adapters", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - net/sched: hhf: clear heavy-hitter state on reset", " - afs: Fix vllist leak", " - afs: Fix unchecked-length string display in debug statement", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - net: qualcomm: rmnet: add tx packets aggregation", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - octeontx2-af: debugfs: Add channel and channel mask.", " - octeontx2-af: Use hashed field in MCAM key", " - octeontx2-af: Exact match support", " - octeontx2-af: Exact match scan from kex profile", " - octeontx2-af: devlink configuration support", " - octeontx2-af: FLR handler for exact match table.", " - octeontx2-af: Drop rules for NPC MCAM", " - octeontx2-af: Allow mkex profile without DMAC and add L2M/L2B header", " extraction support", " - octeontx2-pf: Add additional checks while configuring ucast/bcast/mcast", " rules", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - regulator: core: Make regulator_lock_two() logic easier to follow", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_nat: reject unsupported target families", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - x86/boot: Reject too long acpi_rsdp= values", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: fix VLAN priority offset", " - mfd: tps6586x: Fix OF node refcount", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - proc: only bump parent nlink when registering directories", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - xfrm: use compat translator only for u64 alignment mismatch", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - time: Fix off-by-one in compat settimeofday() usec validation", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm-verity: increase sprintf buffer size", " - scsi: sg: Report request-table problems when any status is set", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - gpios: palmas: add .get_direction() op", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - hwmon: (asus_atk0110) Check package count before accessing element", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - wifi: mac80211: free ack status frame on TX header build failure", " - mtd: onenand: samsung: report DMA completion timeouts", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: imu: inv_icm42600: make timestamp module chip independent", " - iio: move inv_icm42600 timestamp module in common", " - iio: make invensense timestamp module generic", " - iio: imu: inv_mpu6050: use the common inv_sensors timestamp module", " - [Config] Enable CONFIG_IIO_INV_SENSORS_TIMESTAMP=m", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - cifs: Create a new shared file holding smb2 pdu definitions", " - cifs: remove check of list iterator against head past the loop body", " - smb2: small refactor in smb2_check_message()", " - cifs: remove unused server parameter from calc_smb_size()", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - staging: rtl8723bs: Fix indentation issues", " - staging: rtl8723bs: Fix space issues", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - staging: rtl8723bs: Remove redundant else branches.", " - staging: rtl8723bs: remove redundant braces in if statements", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use new GPIO line value setter callbacks", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()", " - cifs: Add tracing for the cifs_tcon struct refcounting", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - ksmbd: fix use-after-free in __ksmbd_close_fd() via durable scavenger", " - ksmbd: destroy async_ida in ksmbd_conn_free()", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - X.509: Fix validation of ASN.1 certificate header", " - proc: use generic setattr() for /proc/$PID/net", " - proc: Move fdinfo PTRACE_MODE_READ check into the inode .permission", " operation", " - proc: rename proc_setattr to proc_nochmod_setattr", " - HID: add haptics page defines", " - treewide: Switch/rename to timer_delete[_sync]()", " - serial: 8250_mid: Remove 8250_pci usage", " - serial: 8250_mid: Disable DMA for selected platforms", " - xfs: Remove redundant assignment of mp", " - xfs: Remove dead code", " - xfs: use null daddr for unset first bad log block", " - hfs/hfsplus: prevent getting negative values of offset/length", " - xdp: introduce flags field in xdp_buff/xdp_frame", " - bpf: Convert lpm_trie.c to rqspinlock", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - usb: iowarrior: remove inherent race with minor number", " - drm/i2c/sil164: Drop no-op remove function", " - leds: lm3697: Remove duplicated error reporting in .remove()", " - leds: lm3601x: Improve error reporting for problems during .remove()", " - gpio: pca953x: Make platform teardown callback return void", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel-sha204a - Mark OF related data as maybe unused", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - crypto: qat - fix restarting state leak on allocation failure", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - ALSA: seq: Avoid confusion of aligned read size", " - iio: imu: inv_mpu6050: fix frequency setting when chip is off", " - iio: invensense: fix odr switching to same value", " - ALSA: seq: Skip event type filtering for UMP events", " - ALSA: seq: Check UMP support for midi_version change", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - Linux 5.15.212", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72282", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72068", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64301", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64304", " - crypto: qat - validate RSA CRT component lengths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64593", " - btrfs: do not trim a device which is not writeable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64594", " - usb: gadget: f_fs: initialize reset_work at allocation time", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68456", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64329", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64352", " - bpf: Allow LPM map access from sleepable BPF programs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64355", " - bpf: Reject fragmented frames in devmap", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64361", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64363", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64371", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64364", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64375", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64390", " - ksmbd: track the connection owning a byte-range lock", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-31610", " - ksmbd: fix mechToken leak when SPNEGO decode fails after token alloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64380", " - smb: client: harden POSIX SID length parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64379", " - smb: client: mask server-provided mode to 07777 in modefromsid", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64401", " - smb: client: resolve SWN tcon from live registrations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64381", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64206", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64413", " - netfilter: ebtables: zero chainstack array", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64428", " - gpio: sch: use raw_spinlock_t in the irq startup path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64438", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64441", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64461", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64446", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64448", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64462", " - PCI: altera: Fix resource leaks on probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64475", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64488", " - ALSA: aoa: check snd_ctl_new1() return value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64510", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64512", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68466", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68467", " - mtd: mchp23k256: use SPI match data for chip caps", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68469", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68474", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68475", " - reset: sunxi: fix memory region leak on ioremap failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68477", " - ipvs: fix more places with wrong ipv6 transport offsets", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68478", " - memstick: ms_block: reject a card that reports too many blocks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68479", " - Bluetooth: btrtl: validate firmware patch bounds", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72004", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72005", " - wifi: rt2x00: avoid full teardown before work setup in probe", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72010", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72013", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72014", " - drbd: reject data replies with an out-of-range payload size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72020", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72021", " - ipvs: use parsed transport offset in SCTP state lookup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72022", " - llc: fix SAP refcount leak in llc_ui_autobind()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72024", " - mac802154: remove interfaces with RCU list deletion", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72025", " - s390/monwriter: Reject buffer reuse with different data length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72033", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72036", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72038", " - net: liquidio: fix BAR resource leak on PF number failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72039", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72229", " - batman-adv: clean untagged VLAN on netdev registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72232", " - batman-adv: ensure minimal ethernet header on TX", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72235", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64534", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72047", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72048", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72049", " - ieee802154: admin-gate legacy LLSEC dump operations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72052", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72054", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72055", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72056", " - net: ena: clean up XDP TX queues when regular TX setup fails", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72061", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72066", " - cpu: hotplug: Bound hotplug states sysfs output", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72067", " - cpu: hotplug: Preserve per instance callback errors", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72074", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72076", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72078", " - Input: ims-pcu - validate control endpoint type", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72079", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72081", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72082", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72083", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72084", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72085", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72086", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72088", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72102", " - dm_early_create: fix freeing used table on dm_resume failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72105", " - dm-log: fix a bitset_size overflow on 32bit machines", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72107", " - dm era: fix out-of-bounds memory access for non-zero start sector", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72108", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72109", " - net: sparx5: unregister blocking notifier on init failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72120", " - can: bcm: add missing rcu list annotations and operations", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72122", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72126", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72129", " - nvmet-rdma: handle inline data with a nonzero offset", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64551", " - sctp: validate STALE_COOKIE cause length before reading staleness", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72133", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72135", " - tpm: Make the TPM character devices non-seekable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72136", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72138", " - xen/gntdev: fix error handling in ioctl", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72140", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72153", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72159", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72160", " - ocfs2: reject dinodes with non-canonical i_mode type", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72163", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72164", " - ocfs2: avoid moving extents to occupied clusters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72165", " - mtd: rawnand: fix condition in 'nand_select_target()'", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72166", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72167", " - mtd: rawnand: pl353: fix probe resource allocation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72171", " - mtd: slram: remove failed entries from the device list", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72181", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72182", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72192", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72193", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64532", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72194", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64533", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72195", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72197", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72215", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72218", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72219", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72223", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72224", " - nvdimm/btt: Free arenas on btt_init() error paths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72225", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72226", " - batman-adv: tt: prevent TVLV OOB check overflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72228", " - batman-adv: frag: fix primary_if leak on failed linearization", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72230", " - batman-adv: frag: free unfragmentable packet", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72231", " - batman-adv: tt: avoid request storms during pending request", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72233", " - batman-adv: bla: reacquire gw address after skb realloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72234", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72238", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72240", " - mfd: sm501: Fix reference leak on failed device registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72241", " - leds: uleds: Fix potential buffer overread", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72245", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64554", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72247", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72250", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72251", " - netfilter: nf_nat_sip: reload possible stale data pointer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72256", " - netfilter: xt_cluster: reject template conntracks in hash match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72264", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72265", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72267", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72268", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72269", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72270", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72271", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72272", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72274", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72275", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72276", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72289", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72296", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72297", " - net: atm: reject out-of-range traffic classes in QoS validation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72298", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72306", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72307", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72310", " - smb: client: fix overflow in passthrough ioctl bounds check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72314", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72316", " - dm era: fix NULL pointer dereference in metadata_open()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72319", " - ipvs: ensure inner headers in ICMP errors are in headroom", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72322", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72326", " - net/sched: cake: reject overhead values that underflow length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64549", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64541", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64550", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72339", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72347", " - netfilter: xt_connmark: reject invalid shift parameters", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72348", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72349", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72350", " - netfilter: xt_u32: reject invalid shift counts", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72351", " - gue: validate REMCSUM private option length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64547", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72371", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72374", " - afs: Fix callback service message parsers to pass through -EAGAIN", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72378", " - afs: Fix error code in afs_extract_vl_addrs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72389", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64540", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72392", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72396", " - hwmon: adm1275: Prevent reading uninitialized stack", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72400", " - seg6: validate SRH length before reading fixed fields", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72406", " - net: sungem: fix probe error cleanup", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72409", " - net: mvneta: re-enable percpu interrupt on resume", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64530", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72414", " - net: dsa: sja1105: round up PTP perout pin duration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64545", " - net, bpf: check master for NULL in xdp_master_redirect()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72418", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72421", " - ipv4: fib: Don't ignore error route in local/main tables.", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64538", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72422", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64546", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72428", " - bpf: Fix stack slot index in nospec checks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72433", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72435", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72441", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72447", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64553", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72448", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72450", " - xfrm: validate selector family and prefixlen during match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72459", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72460", " - apparmor: check label build before no_new_privs test", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72466", " - xprtrdma: Fix bcall rep leak and unbounded peek", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72476", " - dmaengine: Fix possible use after free", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72479", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72481", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72483", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72484", " - staging: most: video: avoid double free on video register failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72489", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72491", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72492", " - ksmbd: fix use-after-free in same_client_has_lease()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-72502", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74255", " - tipc: fix UAF in tipc_l2_send_msg()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74256", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64548", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74262", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74265", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74267", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74276", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74279", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74280", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74281", " - tipc: reject inverted service ranges from peer bindings", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74282", " - tipc: prevent snt_unacked underflow on CONN_ACK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74283", " - tipc: require net admin for TIPCv2 netlink mutators", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74284", " - net/sched: sch_hfsc: Don't make class passive twice", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74287", " - sctp: validate embedded address parameter length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64537", " - bridge: cfm: reject invalid CCM interval at configuration time", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74288", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74292", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74293", " - ASoC: fsl: fsl_audmix: Validate written enum values", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74295", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74297", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74305", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74312", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74313", " - vduse: hold vduse_lock across IDR lookup in open path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74320", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74321", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74327", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74329", " - watchdog: unregister PM notifier on watchdog unregister", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74330", " - configfs: fix lockless traversals of ->s_children", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74331", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74339", " - ALSA: seq: Clear variable event pointer on read", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74340", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74346", " - RDMA/irdma: Fix OOB read during CQ MR registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74348", " - ocfs2/dlm: require a ref for locking_state debugfs open", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74349", " - ocfs2: reject FITRIM ranges shorter than a cluster", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74351", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74359", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74363", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74376", " - md/raid10: reset read_slot when reusing r10bio for discard", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74379", " - dax/kmem: account for partial discontiguous resource upon removal", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74382", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74384", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74390", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74394", " - RDMA/srpt: fix integer overflow in immediate data length check", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74395", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74398", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74399", " - evm: terminate and bound the evm_xattrs read buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64544", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74402", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74408", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74410", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74416", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74424", " - fbcon: fix NULL pointer dereference for a console without vc_data", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74426", " - afs: fix NULL pointer dereference in afs_get_tree()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74427", " - afs: Fix netns teardown to cancel the preallocation charger", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74438", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-74578", " - crypto: algif_skcipher - force synchronous processing on trees without", " ctx->state", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64600", " - xfs: resample the data fork mapping after cycling ILOCK", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64187", " - xfs: fail recovery on a committed log item with no regions", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64266", " - fuse: re-lock request before returning from fuse_ref_folio()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64268", " - RDMA/siw: bound Read Response placement to the RREAD length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64269", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64271", " - Input: touchwin - reset the packet index on every complete packet", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64273", " - Input: iforce - bound the device-reported force-feedback effect index", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64274", " - Input: goodix - clamp the device-reported contact count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64275", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64276", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64277", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64279", " - i2c: core: fix adapter deregistration race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64604", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64296", " - exfat: bound uniname advance in exfat_find_dir_entry()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64298", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64299", " - tracing: Prevent out-of-bounds read in glob matching", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64303", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64306", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64312", " - crypto: pcrypt - restore callback for non-parallel fallback", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64313", " - crypto: ecc - Fix carry overflow in vli multiplication", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64315", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64315 // CVE-2026-64316", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64317", " - isofs: bound Rock Ridge symlink components to the SL record", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64318", " - partitions: aix: bound the pp_count scan to the ppe array", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64322", " - udf: validate sparing table length as an entry count, not a byte count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64323", " - udf: validate VAT header length against the VAT inode size", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64324", " - udf: validate free block extents against the partition length", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64330", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64331", " - usbip: vudc: fix NULL deref in vep_dequeue()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64332", " - USB: ulpi: fix memory leak on registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64333", " - USB: serial: digi_acceleport: fix write buffer corruption", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64334", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64335", " - USB: serial: digi_acceleport: fix broken rx after throttle", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64336", " - USB: serial: keyspan_pda: fix information leak", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64337", " - usb: mtu3: unmap request DMA on queue failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64338", " - USB: misc: uss720: unregister parport on probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64340", " - USB: legousbtower: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64342", " - USB: iowarrior: fix use-after-free on disconnect", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64343", " - USB: ldusb: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64344", " - USB: idmouse: fix use-after-free on disconnect race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64346", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64347", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64350", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64351", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64359", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64360", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64362", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68091", " - HID: wacom: stop hardware after post-start probe failures", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64370", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64372", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64373", " - cpufreq: Fix hotplug-suspend race during reboot", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64374", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64403", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64408", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64411", " - netfilter: ebtables: terminate table name before find_table_lock()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64412", " - netfilter: ebtables: module names must be null-terminated", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64420", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64422", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64423", " - ipv4: igmp: remove multicast group from hash table on device destruction", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64425", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64429", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64430", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64432", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68090", " - debugobjects: Plug race against a concurrent OOM disable", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64435", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64436", " - net: af_key: initialize alg_key_len for IPComp states", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64599", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64440", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64536", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64442", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64443", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64444", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64445", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64450", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64452", " - 6lowpan: fix NHC entry use-after-free on error path", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64454", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64455", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64456", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64189", " - netfilter: ipset: fix race between dump and ip_set_list resize", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64465", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64468", " - binder: fix UAF in binder_free_transaction()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64469", " - binder: fix UAF in binder_thread_release()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64470", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64471", " - Bluetooth: btusb: fix use-after-free on registration failure", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64478", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64483", " - ALSA: firewire: isight: bound the sample count to the packet payload", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64484", " - ALSA: es1938: check snd_ctl_new1() return value", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64487", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64494", " - iio: light: gp2ap002: fix runtime PM leak on read error", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64495", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64496", " - iio: event: Fix event FIFO reset race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64497", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64602", " - iio: adc: spear: Initialize completion before requesting IRQ", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64500", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64503", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64504", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64505", " - usb: gadget: function: rndis: add length check for header", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68088", " - usb: gadget: function: rndis: add length check to response query", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53392", " - NFSv4/flexfiles: reject zero filehandle version count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53402", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63810", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68459", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68460", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63815", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63818", " - f2fs: validate orphan inode entry count", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-68461", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63829", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53332", " - slimbus: qcom-ngd-ctrl: Register callbacks after creating the ngd", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2022-3114", " - clk: imx: Add check for kcalloc", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-64514", " - userfaultfd: gate must_wait writability check on pte_present()", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", " * Jammy update: v5.15.212 upstream stable release (LP: #2165124) //", " CVE-2026-53399", " - nfsd: release layout stid on setlease failure", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176)", " - Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size", " - net/sched: sch_sfb: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - drm: Remove plane hsub/vsub alignment requirement for core helpers", " - nfc: llcp: Fix use-after-free in llcp_sock_release()", " - nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()", " - xfrm: Check for underflow in xfrm_state_mtu", " - nfc: nxp-nci: i2c: use rising-edge IRQ on ACPI systems", " - netfilter: xt_cpu: prefer raw_smp_processor_id", " - net: netlink: fix sending unassigned nsid after assigned one", " - net: netlink: don't set nsid on local notifications", " - net/smc: Do not re-initialize smc hashtables", " - net/iucv: fix locking in .getsockopt", " - ipv4: free net->ipv4.sysctl_local_reserved_ports after", " unregister_net_sysctl_table()", " - ASoC: Intel: bytcht_es8316: Fix MCLK leak on init errors", " - ASoC: codecs: simple-mux: Fix enum control bounds check", " - Bluetooth: 6lowpan: check skb_clone() return value in send_mcast_pkt()", " - bonding: refuse to enslave CAN devices", " - ethtool: eeprom: add more safeties to EEPROM Netlink fallback", " - Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success", " - Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp", " - gpio: rockchip: convert bank->clk to devm_clk_get_enabled()", " - sctp: fix race between sctp_wait_for_connect and peeloff", " - batman-adv: tvlv: abort OGM send on tvlv append failure", " - batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface", " - batman-adv: iv: recover OGM scheduling after forward packet error", " - selftests: forwarding: lib: Add helpers for checksum handling", " - batman-adv: tp_meter: directly shut down timer on cleanup", " - batman-adv: tt: avoid empty VLAN responses", " - batman-adv: bla: avoid double decrement of bla.num_requests", " - drm/i915/psr: Add defininitions for INTEL_WA_REGISTER_CAPS DPCD register", " - drm/i915/psr: Read Intel DPCD workaround register", " - drm/dp: Add eDP 1.5 bit definition", " - drm/i915/psr: Apply Intel DPCD workaround when SDP on prior line used", " - phy: mscc: Use PHY_ID_MATCH_VENDOR to minimize PHY ID table", " - phy: mscc: Use PHY_ID_MATCH_EXACT for VSC8584, VSC8582, VSC8575, VSC856X", " - iio: imu: st_lsm6dsx: fix stack leak in tagged FIFO buffer", " - usb: typec: ucsi: ccg: reject firmware images without a ':' record", " header", " - usb: typec: ucsi: displayport: NAK DP_CMD_CONFIGURE without a payload", " VDO", " - usb: typec: altmodes/displayport: validate count before reading Status", " Update VDO", " - usb: typec: wcove: don't write past struct pd_message in", " wcove_read_rx_buffer()", " - USB: serial: safe_serial: fix memory corruption with small endpoint", " - Input: ims-pcu - fix usb_free_coherent() size in ims_pcu_buffers_free()", " - Bluetooth: btusb: Allow firmware re-download when version matches", " - hpfs: fix a crash if hpfs_map_dnode_bitmap fails", " - Bluetooth: L2CAP: fix chan ref leak in l2cap_chan_timeout() on !conn", " - Bluetooth: HIDP: fix missing length checks in hidp_input_report()", " - parport: Fix race between port and client registration", " - iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux", " - iio: dac: max5821: fix return value check in powerdown sync", " - iio: dac: ad5686: fix input raw value check", " - wireguard: send: append trailer after expanding head", " - iio: adc: viperboard: Fix error handling in vprbrd_iio_read_raw", " - iio: gyro: itg3200: fix i2c read into the wrong stack location", " - iio: ssp_sensors: cancel delayed work_refresh on remove", " - iio: temperature: tsys01: fix broken PROM checksum validation", " - iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL", " - iio: light: cm3323: fix reg_conf not being initialized correctly", " - iio: buffer: hw-consumer: fix use-after-free in error path", " - USB: serial: omninet: fix memory corruption with small endpoint", " - usb: cdns3: gadget: fix request skipping after clearing halt", " - usb: cdns3: plat: fix unbalanced pm_runtime_forbid() call permanently", " leaks the runtime PM usage counter across bind/unbind cycles", " - usb: dwc2: Fix use after free in debug code", " - Input: elan_i2c - validate firmware size before use", " - bpf: sockmap: fix tail fragment offset in bpf_msg_push_data", " - macsec: fix replay protection at XPN lower-PN wrap", " - ASoC: qcom: q6asm-dai: fix error handling in prepare and set_params", " - ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().", " - ipv6: validate extension header length before copying to cmsg", " - xfrm: input: hold netns during deferred transport reinjection", " - ip6: vti: Use ip6_tnl.net in vti6_changelink().", " - HID: wacom: Fix OOB write in wacom_hid_set_device_mode()", " - iommu, debugobjects: avoid gcc-16.1 section mismatch warnings", " - nfc: hci: fix out-of-bounds read in HCP header parsing", " - xfrm: route MIGRATE notifications to caller's netns", " - xfrm: ah: use skb_to_full_sk in async output callbacks", " - netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without", " direction check", " - ASoC: qcom: q6asm-dai: close stream only when running", " - ASoC: qcom: q6asm-dai: do not set stream state in event and trigger", " callbacks", " - Input: atmel_mxt_ts - fix boundary check in mxt_prepare_cfg_mem", " - Input: synaptics - add LEN2058 to SMBus passlist for ThinkPad E490", " - comedi: comedi_test: fix check for valid scan_begin_src in", " waveform_ai_cmdtest()", " - comedi: comedi_test: Fix limiting of convert_arg in", " waveform_ai_cmdtest()", " - tty: serial: pch_uart: add check for dma_alloc_coherent()", " - usb: chipidea: core: convert ci_role_switch to local variable", " - usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval", " - USB: quirks: add NO_LPM for Lenovo ThinkPad USB-C Dock Gen2 hub", " controllers", " - usb: storage: Add quirks for PNY Elite Portable SSD", " - usbip: vudc: Fix use after free bug in vudc_remove due to race condition", " - usb: usbtmc: check URB actual_length for interrupt-IN notifications", " - usb: usbtmc: reject interrupt endpoints with small wMaxPacketSize", " - USB: serial: option: add MeiG SRM813Q", " - USB: serial: option: add missing RSVD(5) flag for Rolling RW135R-GL", " - USB: serial: belkin_sa: validate interrupt status length", " - USB: serial: cypress_m8: validate interrupt packet headers", " - USB: serial: keyspan: fix missing indat transfer sanity check", " - USB: serial: mxuport: fix memory corruption with small endpoint", " - USB: serial: mct_u232: fix missing interrupt-in transfer sanity check", " - usb: gadget: net2280: Fix double free in probe error path", " - usb: gadget: dummy_hcd: Reject hub port requests for non-existent ports", " - usb: gadget: f_fs: copy only received bytes on short ep0 read", " - thunderbolt: property: Reject u32 wrap in tb_property_entry_valid()", " - thunderbolt: property: Reject dir_len < 4 to prevent size_t underflow", " - scsi: fcoe: Reject FIP descriptors with zero fip_dlen in CVL walker", " - scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32", " - drm/hyperv: validate VMBus packet size in receive callback", " - serial: sh-sci: fix memory region release in error path", " - serial: zs: Fix swapped RI/DSR modem line transition counting", " - serial: fsl_lpuart: fix rx buffer and DMA map leaks in start_rx_dma", " - serial: dz: Fix bootconsole message clobbering at chip reset", " - serial: zs: Fix bootconsole handover lockup", " - serial: zs: Switch to using channel reset", " - USB: serial: cypress_m8: fix memory corruption with small endpoint", " - HID: core: Add printk_ratelimited variants to hid_warn() etc", " - HID: pass the buffer size to hid_report_raw_event", " - HID: core: Fix size_t specifier in hid_report_raw_event()", " - USB: serial: digi_acceleport: fix memory corruption with small endpoints", " - xhci: tegra: Fix ghost USB device on dual-role port unplug", " - serial: dz: Fix bootconsole handover lockup", " - usb: core: Fix SuperSpeed root hub wMaxPacketSize", " - USB: serial: mct_u232: fix memory corruption with small endpoint", " - compiler-clang.h: Add __diag infrastructure for clang", " - Disable -Wattribute-alias for clang-23 and newer", " - netfilter: xt_NFQUEUE: prefer raw_smp_processor_id", " - drm/imx: Fix three kernel-doc warnings in dcss-scaler.c", " - pcnet32: stop holding device spin lock during napi_complete_done", " - net: garp: fix unsigned integer underflow in garp_pdu_parse_attr", " - net: lan743x: permit VLAN-tagged packets up to configured MTU", " - Bluetooth: bnep: fix incorrect length parsing in bnep_rx_frame()", " extension handling", " - ieee802154: 6lowpan: only accept IPv6 packets in lowpan_xmit()", " - signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()", " - time: Fix off-by-one in settimeofday() usec validation", " - KVM: arm64: Remove VPIPT I-cache handling", " - arm64: tlb: Allow XZR argument to TLBI ops", " - arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBI", " - rds: mark snapshot pages dirty in rds_info_getsockopt()", " - net: mvpp2: Add metadata support for xdp mode", " - net: mvpp2: build skb from XDP-adjusted data on XDP_PASS", " - drm/i915/gem: Fix phys BO pread/pwrite with offset", " - USB: serial: option: add usb-id for Dell Wireless DW5826e-m", " - ALSA: timer: Fix UAF at snd_timer_user_params()", " - drm/amd/display: Reject gpio_bitshift >= 32 in", " bios_parser_get_gpio_pin_info()", " - ARM: socfpga: Fix OF node refcount leak in SMP setup", " - ARM: 9474/1: io: avoid KASAN instrumentation of raw halfword I/O", " - mptcp: fix retransmission loop when csum is enabled", " - mptcp: sockopt: check timestamping ret value", " - pidfd: refuse access to tasks that have started exiting harder", " - i2c: qcom-cci: Fix NULL pointer dereference in cci_remove()", " - i2c: stm32f7: fix timing computation ignoring i2c-analog-filter", " - i2c: tegra: Fix NOIRQ suspend/resume", " - Input: atkbd - add DMI quirk for Lenovo Yoga Air 14 (83QK)", " - Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard", " - net: bonding: fix NULL pointer dereference in bond_do_ioctl()", " - net: mv643xx: fix OF node refcount", " - mmc: core: Fix host controller programming for fixed driver type", " - mmc: renesas_sdhi: Add OF entry for RZ/G2H SoC", " - mmc: sdhci: add signal voltage switch in sdhci_resume_host", " - slimbus: qcom-ngd-ctrl: Avoid ABBA on tx_lock/ctrl->lock", " - drm/amd/display: Use krealloc_array() in dal_vector_reserve()", " - fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling", " - mm/damon/ops-common: call folio_test_lru() after folio_get()", " - SAUCE: Revert \"net/tcp-md5: Fix MAC comparison to be constant-time\"", " - f2fs: fix to do sanity check on dcc->discard_cmd_cnt conditionally", " - smb: server: fix max_connections off-by-one in tcp accept path", " - arm64/mm: Enable batched TLB flush in unmap_hotplug_range()", " - rtw88: 8821ce: Disable PCIe ASPM L1 for 8821CE using chip ID", " - ALSA: aoa: Use guard() for mutex locks", " - ALSA: aoa: i2sbus: clear stale prepared state", " - media: rc: ttusbir: respect DMA coherency rules", " - ALSA: aoa: Skip devices with no codecs in i2sbus_resume()", " - sched: Use u64 for bandwidth ratio calculations", " - ALSA: core: Fix potential data race at fasync handling", " - net: qrtr: ns: Change servers radix tree to xarray", " - net: mctp: fix don't require received header reserved bits to be zero", " - randomize_kstack: Maintain kstack_offset per task", " - mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration", " - mtd: spi-nor: sst: Fix write enable before AAI sequence", " - can: ucan: fix typos in comments", " - printk: add print_hex_dump_devel()", " - usb: typec: tcpm: reset internal port states on soft reset AMS", " - usb: dwc3: Move GUID programming after PHY initialization", " - net: ipv4: stop checking crypto_ahash_alignmask", " - net: ipv6: stop checking crypto_ahash_alignmask", " - spi: syncuacer: fix controller deregistration", " - spi: sun4i: fix controller deregistration", " - spi: spi-ti-qspi: Convert to platform remove callback returning void", " - spi: ti-qspi: fix controller deregistration", " - spi: zynq-qspi: fix controller deregistration", " - spi: sun6i: fix controller deregistration", " - spi: tegra114: fix controller deregistration", " - spi: tegra20-sflash: fix controller deregistration", " - spi: uniphier: fix controller deregistration", " - mm/hugetlb_cma: round up per_node before logging it", " - spi: topcliff-pch: Convert to platform remove callback returning void", " - spi: topcliff-pch: fix controller deregistration", " - tracing/probes: Limit size of event probe to 3K", " - SAUCE: Revert \"smb: client: validate dacloffset before building DACL", " pointers\"", " - smb: client: Use FullSessionKey for AES-256 encryption key derivation", " - mptcp: pm: prio: skip closed subflows", " - mptcp: pm: ADD_ADDR rtx: resched blocked ADD_ADDR quicker", " - f2fs: fix incorrect file address mapping when inline inode is unwritten", " - f2fs: fix false alarm of lockdep on cp_global_sem lock", " - spi: st-ssc4: fix controller deregistration", " - spi: lantiq-ssc: fix controller deregistration", " - genetlink: Use internal flags for multicast groups", " - smb: client: require net admin for CIFS SWN netlink", " - Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()", " - Bluetooth: hci_qca: Convert timeout from jiffies to ms", " - Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 2", " - Bluetooth: MGMT: validate Add Extended Advertising Data length", " - qed: Use the bitmap API to simplify some functions", " - qed: fix double free in qed_cxt_tables_alloc()", " - Bluetooth: Consolidate code around sk_alloc into a helper function", " - Bluetooth: Init sk_peer_* on bt_sock_alloc", " - net: hsr: defer node table free until after RCU readers", " - ice: fix VF queue configuration with low MTU values", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ioam: add NULL check for idev in ipv6_hop_ioam()", " - use less confusing names for iov_iter direction initializers", " - mptcp: pm: fix ADD_ADDR timer infinite retry on option space", " insufficient", " - selftests: mptcp: drop nanoseconds width specifier", " - mptcp: do not drop partial packets", " - octeontx2-af: CGX: add bounds check to cgx_speed_mbps index", " - octeontx2-pf: avoid double free of pool->stack on AQ init failure", " - spi: qup: switch to use modern name", " - spi: qup: fix error pointer deref after DMA setup failure", " - arm64: tlb: Flush walk cache when unsharing PMD tables", " - phy: tegra: xusb: Disable trk clk when not in use", " - phy: tegra: xusb: Fix per-pad high-speed termination calibration", " - Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()", " - iio: gyro: adis16260: fix division by zero in write_raw", " - iio: chemical: scd30: Use guard(mutex) to allow early returns", " - iio: chemical: scd30: fix division by zero in write_raw", " - iio: dac: ad5686: fix ref bit initialization for single-channel parts", " - usb: cdns3: plat: fix leaked usb2_phy initialization on usb3_phy", " acquisition failure", " - serial: samsung_tty: Use port lock wrappers", " - tty: serial: samsung: use u32 for register interactions", " - tty: serial: samsung: Remove redundant port lock acquisition in rx", " helpers", " - usb: dwc3: xilinx: fix error handling in zynqmp init error paths", " - usb: gadget: f_hid: tidy error handling in hidg_alloc", " - usb: gadget: f_hid: fix device reference leak in hidg_alloc()", " - thunderbolt: property: Cap recursion depth in __tb_property_parse_dir()", " - drm/hyperv: Remove support for Hyper-V 2008 and 2008R2/Win7", " - drm/hyperv: validate resolution_count and fix WIN8 fallback", " - serial: altera_jtaguart: Use platform_get_irq_optional() to get the", " interrupt", " - serial: altera_jtaguart: handle uart_add_one_port() failures", " - tty: serial: qcom-geni-serial: remove unused symbols", " - tty: serial: qcom-geni-serial: align #define values", " - serial: qcom-geni: fix UART_RX_PAR_EN bit position", " - RDMA/umem: fix kernel-doc warnings", " - RDMA: Move DMA block iterator logic into dedicated files", " - batman-adv: tp_meter: fix tp_num leak on kmalloc failure", " - SAUCE: Revert \"net/ipv6: ioam6: prevent schema length wraparound in", " trace fill\"", " - SAUCE: Revert \"nfsd: fix heap overflow in NFSv4.0 LOCK replay cache\"", " - ALSA: hda/hdmi: Add quirk for TUXEDO IBS14G6", " - selinux: enable genfscon labeling for securityfs", " - arm64: cputype: Add NVIDIA Olympus definitions", " - arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU", " - mptcp: close TOCTOU race while computing rcv_wnd", " - fbdev: vt8500lcdfb: Fix dma_free_coherent() cpu_addr parameter", " - SAUCE: Revert \"apparmor: validate DFA start states are in bounds in", " unpack_pdb\"", " - apparmor: validate DFA start states are in bounds in unpack_pdb", " - apparmor: validate default DFA states are in bounds", " - media: rc: ttusbir: fix inverted error logic", " - batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown", " - media: rc: igorplugusb: fix control request setup packet", " - Bluetooth: MGMT: Fix backward compatibility with userspace", " - ksmbd: OOB read regression in smb_check_perm_dacl() ACE-walk loops", " - batman-adv: tp_meter: fix race condition in send error reporting", " - batman-adv: tp_meter: avoid role confusion in tp_list", " - Linux 5.15.210", " - drm/v3d: Store the active job inside the queue's state", " - batman-adv: tt: reject oversized local TVLV buffers", " - batman-adv: tt: prevent TVLV entry number overflow", " - vfio/iommu_type1: replace kfree with kvfree", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - i2c: stub: Reject I2C block transfers with invalid length", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", " - xhci: fix memory leak regression when freeing xhci vdev devices depth", " first", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", " - virtiofs: fix UAF on submount umount", " - Revert \"selftest/ptp: update ptp selftest to exercise the gettimex", " options\"", " - Revert \"ptp: add testptp mask test\"", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", " - kselftest/arm64: signal: Skip SVE signal test if not enough VLs", " supported", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: v: prevent OGM aggregation on disabled hardif", " - batman-adv: tp_meter: restrict number of unacked list entries", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - ring-buffer: Remove ring_buffer_read_prepare_sync()", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", " - mac802154: llsec: add skb_cow_data() before in-place crypto", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", " - keys: Pin request_key_auth payload in instantiate paths", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: ath11k: fix warning when unbinding", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", " - bpf: use kvfree() for replaced sysctl write buffer", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", " - fpga: region: fix use-after-free in child_regions_with_firmware()", " - ocfs2: reject oversized group bitmap descriptors", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: fix posix_acl leak on SETACL decode failure", " - nfsd: check get_user() return when reading princhashlen", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", " - mptcp: fix missing wakeups in edge scenarios", " - hv: utils: handle and propagate errors in kvp_register", " - misc: fastrpc: Add dma_mask to fastrpc_channel_ctx", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - fuse: re-lock request before replacing page cache folio", " - ksmbd: reject non-VALID session in compound request branch", " - Documentation: ioctl-number: Extend \"Include File\" column width", " - crypto: qat - Replace kzalloc() + copy_from_user() with memdup_user()", " - crypto: qat - Return pointer directly in adf_ctl_alloc_resources", " - crypto: qat - remove unused character device and IOCTLs", " - Linux 5.15.211", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53158", " - misc: fastrpc: Fix NULL pointer dereference in rpmsg callback", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39931", " - crypto: af_alg - Set merge to zero early in af_alg_sendmsg", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31451", " - ext4: add bounds check for inline data length in ext4_read_inline_page", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43355", " - iio: light: bh1780: fix PM runtime leak on error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53139", " - drm/v3d: Skip CSD when it has zeroed workgroups", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53138", " - drm/amd/display: Bound VBIOS record-chain walk loops", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses", " - arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31402", " - nfsd: fix heap overflow in NFSv4.0 LOCK replay cache", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-23364", " - ksmbd: Compare MACs in constant time", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43341", " - net/ipv6: ioam6: prevent schema length wraparound in trace fill", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46208", " - batman-adv: stop tp_meter sessions during mesh teardown", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2023-54271", " - blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed", " before init", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45850", " - ipvs: skip ipv6 extension headers for csum checks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53189", " - mm/huge_memory: update file PMD counter before folio_put()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53133", " - RDMA/umem: Fix truncation for block sizes >= 4G", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53199", " - hv_netvsc: use kmap_local_page in netvsc_copy_to_send_buf", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53134", " - netfilter: nft_fib: fix stale stack leak via the OIFNAME register", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52943", " - net: skbuff: fix missing zerocopy reference in pskb_carve helpers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52918", " - Bluetooth: serialize accept_q access", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46160", " - btrfs: fix missing last_unlink_trans update when removing a directory", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46195", " - smb: client: validate dacloffset before building DACL pointers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46292", " - pmdomain: core: Fix detach procedure for virtual devices in genpd", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46159", " - btrfs: fix btrfs_ioctl_space_info() slot_count TOCTOU which can lead to", " info-leak", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46191", " - fbcon: Avoid OOB font access if console rotation fails", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46116", " - xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46193", " - xfrm: ah: account for ESN high bits in async callbacks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46180", " - wifi: brcmfmac: Fix potential use-after-free issue when stopping", " watchdog task", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31709", " - smb: client: validate the whole DACL before rewriting it in cifsacl", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46196", " - tracepoint: balance regfunc() on func_add() failure in", " tracepoint_add_func()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46291", " - crypto: caam - guard HMAC key hex dumps in hash_digest_key", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46090", " - ALSA: aloop: Fix peer runtime UAF during format-change stop", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46052", " - ceph: only d_add() negative dentries when they are unhashed", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45999", " - erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46103", " - can: ucan: fix devres lifetime", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46056", " - Bluetooth: hci_event: fix potential UAF in SSP passkey handlers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46299", " - hfsplus: fix held lock freed on hfsplus_fill_super()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46169", " - hfsplus: fix uninit-value by validating catalog record size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45991", " - udf: fix partition descriptor append bookkeeping", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46065", " - fbdev: defio: Disconnect deferred I/O from the lifetime of struct", " fb_info", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46086", " - net: bridge: use a stable FDB dst snapshot in RCU readers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46003", " - net: qrtr: ns: Limit the total number of nodes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46038", " - net: qrtr: ns: Free the node during ctrl_cmd_bye()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46026", " - net: qrtr: ns: Limit the maximum number of lookups", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46091", " - media: rc: igorplugusb: heed coherency rules", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46078", " - erofs: fix the out-of-bounds nameoff handling for trailing dirents", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46069", " - wifi: mwifiex: fix use-after-free in mwifiex_adapter_cleanup()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46021", " - thermal: core: Fix thermal zone governor cleanup issues", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46092", " - wifi: rtw88: check for PCI upstream bridge existence", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31700", " - net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31712", " - ksmbd: require minimum ACE size in smb_check_perm_dacl()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31708", " - smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43350", " - smb: client: require a full NFS mode SID before reading mode bits", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31711", " - smb: server: fix active_num_conn leak on transport allocation failure", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31715", " - f2fs: fix UAF caused by decrementing sbi->nr_pages[] in", " f2fs_write_end_io()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43492", " - lib/crypto: mpi: Fix integer underflow in mpi_read_raw_from_sgl()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43383", " - net/tcp-md5: Fix MAC comparison to be constant-time", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52933", " - io_uring/poll: fix signed comparison in io_poll_get_ownership()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53135", " - drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53136", " - drm/amd/display: Clamp VBIOS HDMI retimer register count to array size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53137", " - drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53146", " - thunderbolt: Limit XDomain response copy to actual frame size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53148", " - thunderbolt: Clamp XDomain response data copy to allocation size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53149", " - thunderbolt: Bound root directory content to block size", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53150", " - thunderbolt: Reject zero-length property entries in validator", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52929", " - sctp: stream: fully roll back denied add-stream state", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52917", " - sctp: diag: reject stale associations in dump_one path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53159", " - misc: fastrpc: fix DMA address corruption due to find_vma misuse", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53161", " - misc: fastrpc: fix use-after-free of fastrpc_user in workqueue context", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52930", " - ipc/shm: serialize orphan cleanup with shm_nattch updates", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53168", " - fuse: reject fuse_notify() pagecache ops on directories", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53177", " - bnxt_en: Fix NULL pointer dereference", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53181", " - vsock/vmci: fix sk_ack_backlog leak on failed handshake", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53194", " - USB: serial: kl5kusb105: fix bulk-out buffer overflow", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53195", " - USB: serial: io_ti: fix heap overflow in build_i2c_fw_hdr()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53196", " - USB: serial: io_ti: fix heap overflow in get_manuf_info()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52935", " - xfrm: espintcp: do not reuse an in-progress partial send", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53208", " - Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53213", " - drm/vc4: fix krealloc() memory leak", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53217", " - net: mvpp2: sync RX data at the hardware packet offset", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53218", " - netfilter: nft_exthdr: fix register tracking for F_PRESENT flag", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52942", " - netfilter: nf_log: validate MAC header was set before dumping it", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53219", " - netfilter: x_tables: avoid leaking percpu counter pointers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52939", " - net/rds: fix NULL deref in rds_ib_send_cqe_handler() on masked atomic", " completion", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53223", " - net: guard timestamp cmsgs to real error queue skbs", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53227", " - net: openvswitch: fix possible kfree_skb of ERR_PTR", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52947", " - net: qrtr: fix refcount saturation and potential UAF in qrtr_port_remove", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53238", " - netlabel: validate unlabeled address and mask attribute lengths", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53239", " - xfrm: policy: fix use-after-free on inexact bin in", " xfrm_policy_bysel_ctx()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46322", " - tun: free page on build_skb failure in tun_xdp_one()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46320", " - tap: free page on error paths in tap_get_user_xdp()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-22026", " - nfsd: don't ignore the return code of svc_proc_register()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2023-54125", " - fs/ntfs3: Return error for inconsistent extended attributes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-31449", " - ext4: validate p_idx bounds in ext4_ext_correct_indexes", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53245", " - net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53249", " - ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53252", " - Bluetooth: fix memory leak in error path of hci_alloc_dev()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53253", " - Bluetooth: bnep: reject short frames before parsing", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53254", " - Bluetooth: RFCOMM: validate skb length in MCC handlers", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53255", " - Bluetooth: MGMT: validate advertising TLV before type checks", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53256", " - Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53263", " - 6lowpan: fix off-by-one in multicast context address compression", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53264", " - net/sched: act_api: use RCU with deferred freeing for action lifecycle", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53265", " - dm cache policy smq: check allocation under invalidate lock", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53266", " - netfilter: bridge: make ebt_snat ARP rewrite writable", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53268", " - netfilter: conntrack_irc: fix possible out-of-bounds read", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53269", " - netfilter: synproxy: add mutex to guard hook reference counting", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53270", " - ipvs: clear the svc scheduler ptr early on edit", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53273", " - tee: optee: prevent use-after-free when the client exits before the", " supplicant", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53275", " - ipv6: mcast: Fix use-after-free when processing MLD queries", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52948", " - i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52910", " - bpf: Free reuseport cBPF prog after RCU grace period.", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52923", " - ipc: limit next_id allocation to the valid ID range", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39929", " - smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45852", " - Revert \"RDMA/rxe: Fix double free in rxe_srq_from_init\"", " - RDMA/rxe: Fix double free in rxe_srq_from_init", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2025-39863", " - wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info", " work", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52934", " - batman-adv: tvlv: reject oversized TVLV packets", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52913", " - batman-adv: v: stop OGMv2 on disabled interface", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-46321", " - tun: free page on short-frame rejection in tun_xdp_one()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-52927", " - netfilter: ebtables: fix OOB read in compat_mtw_from_user", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43219", " - net: cpsw_new: Fix potential unregister of netdev that has not been", " registered yet", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-43064", " - dmaengine: idxd: Fix not releasing workqueue on .release()", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-45930", " - net: mctp: ensure our nlmsg responses are initialised", " * Jammy update: v5.15.211 upstream stable release (LP: #2161176) //", " CVE-2026-53080", " - net/sched: cls_fw: fix NULL dereference of \"old\" filters before change()", " * CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", " * CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", " * CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", " * CVE-2025-10263 // CVE-2026-53354", " - arm64: errata: Mitigate TLBI errata on various Arm CPUs", " - [Config] Set CONFIG_ARM64_ERRATUM_4118414=y", " * CVE-2025-10263", " - arm64: cputype: Add C1-Premium definitions", " - arm64: cputype: Add C1-Ultra definitions", " * CVE-2026-63888", " - scsi: target: iscsi: Fix CRC overread and double-free in", " iscsit_handle_text_cmd()", " * CVE-2026-63887", " - scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf", " * CVE-2026-53355", " - net: rds: clear i_sends on setup unwind", " * CVE-2026-53186", " - RDMA/srp: bound SRP_RSP sense copy by the received length", " * CVE-2026-53216", " - net: mvpp2: limit XDP frame size to the RX buffer", " * CVE-2026-63912", " - xfrm: esp: restore combined single-frag length gate", " * CVE-2026-63922", " - ipv6: exthdrs: refresh nh after handling HAO option", " * CVE-2026-63924", " - ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()", " * CVE-2026-64091", " - batman-adv: tt: fix TOCTOU race for reported vlans", " * CVE-2026-63984", " - ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress()", " * CVE-2026-63992", " - tunnels: do not assume transport header in iptunnel_pmtud_check_icmp()", " * CVE-2026-63993", " - vxlan: do not reuse cached ip_hdr() value after skb_tunnel_check_pmtu()", " * CVE-2026-63994", " - tunnels: load network headers after skb_cow() in", " iptunnel_pmtud_build_icmp[v6]()", " * CVE-2026-64007", " - netfilter: synproxy: refresh tcphdr after skb_ensure_writable", " * CVE-2026-53221", " - ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()", " * SAUCE: Revert erroneous application of \"netfilter: nf_tables: fix inverted", " genmask check in nft_map_catchall_activate()\" (LP: #2164800)", " - SAUCE: Revert \"netfilter: nf_tables: fix inverted genmask check in", " nft_map_catchall_activate()\"", "" ], "package": "linux-kvm", "version": "5.15.0-1109.114", "urgency": "medium", "distributions": "jammy", "launchpad_bugs_fixed": [ 2165588, 2166457, 1786013, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2165192, 2163508, 2164699, 1961566, 1956562, 2164516, 2137199, 2165170, 2165170, 2165166, 2165125, 2165125, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2165124, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2161176, 2164800 ], "author": "Thibault Ferrante ", "date": "Thu, 10 Sep 2026 15:20:26 +0200" } ], "notes": "linux-modules-5.15.0-1109-kvm version '5.15.0-1109.114' (source package linux-kvm version '5.15.0-1109.114') was added. linux-modules-5.15.0-1109-kvm version '5.15.0-1109.114' has the same source package name, linux-kvm, as removed package linux-headers-5.15.0-1108-kvm. As such we can use the source package version of the removed package, '5.15.0-1108.113', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-5.15.0-1108-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": "5.15.0-1108.113" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-5.15.0-1108-kvm", "from_version": { "source_package_name": "linux-signed-kvm", "source_package_version": "5.15.0-1108.113", "version": "5.15.0-1108.113" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-kvm-headers-5.15.0-1108", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": "5.15.0-1108.113" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-5.15.0-1108-kvm", "from_version": { "source_package_name": "linux-kvm", "source_package_version": "5.15.0-1108.113", "version": "5.15.0-1108.113" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 22.04 jammy image from daily image serial 20260929 to 20261001", "from_series": "jammy", "to_series": "jammy", "from_serial": "20260929", "to_serial": "20261001", "from_manifest_filename": "daily_manifest.previous", "to_manifest_filename": "manifest.current" }